Incubics

Approach

Governance

Governance is not the department that says no. It is the set of controls that let you ship AI in regulated and operational environments without losing sleep. We treat it as engineering work with documentation, not as a checkbox slide.

Every client arrives with different governance pressure: model risk management in banking, privacy rules in healthcare, safety cases in manufacturing, customer trust in software platforms. Our approach does not sell a one-size compliance product. We capture your requirements in Perceive, implement controls in Engineer, verify at Deliver, and monitor under Run.

Governance in discovery

The discovery pack includes a governance baseline: data classification, residency constraints, logging and retention requirements, approval workflows for model and prompt changes, human oversight points, and alignment to your existing risk frameworks. We interview security, compliance and legal where you involve them — early, not after build.

Use cases are scored for risk as well as value. A high-value use case with unacceptable risk is deprioritised or redesigned with narrower automation — for example, draft-only outputs pending human approval. Honest scoring beats heroic demos that cannot pass review.

Technical controls

Access and data handling

Role-based access to systems, prompts, evaluation data and environments. Retrieval respects document-level permissions. PII handling follows your policy — minimisation in logs, redaction in outputs where required, no training on client data for shared models.

Agent accountability

Every tool invocation logged with attribution. Session replay for investigations within retention policy. Rate limits and circuit breakers on actions with financial or safety impact. Kill switches tested before cutover.

Evaluation as governance evidence

Pre-production evaluation results document expected behaviour and known limitations. Ongoing evaluation under Run demonstrates continued fitness for purpose — the operational heart of model risk management. We align report format to what your risk team needs without claiming certifications we do not hold.

Change control

Models, prompts, retrieval indexes and tool definitions change. Governance requires controlled change: staging regression, approver sign-off, rollback plan, communication to affected users. We implement versioning and promotion workflows that mirror your software change advisory process where one exists.

Human oversight

Fully autonomous action is not always appropriate. We design oversight into the workflow: approval queues, confidence thresholds, dual control for high-value transactions, clinician sign-off on generated notes. The right level is a business and regulatory decision captured in discovery, implemented in code.

Third parties and vendors

When frontier APIs or hosted models are in scope, we document data processing terms, retention, and subprocessors. If a vendor arrangement conflicts with your policy, we propose alternatives — self-hosted open models, different regions, contractual addenda. Surprises at audit time mean discovery failed.

Governance without gridlock

Controls should enable shipping, not prevent it. Parallel security review, pre-agreed patterns for logging and access, and evaluation automation reduce review cycles. We bring templates from prior engagements — architecture patterns, runbook sections, evaluation report structures — adapted to your context, not copied blindly.

Roles and forums

Governance works when roles are clear. Your sponsor decides scope trade-offs. Your risk or compliance team defines non-negotiables. Our engagement lead ensures build artefacts meet those non-negotiables before steering asks for sign-off. We do not bypass your forums — we arrive prepared so forums decide rather than defer.

For regulated clients, we attend model validation or AI review meetings when you invite us — to explain architecture and evaluation, not to replace your accountable executive. Minutes and action items feed the backlog like any other requirement.

Incident and escalation governance

When guardrails fire or evaluation drops, escalation paths defined in Deliver stay active under Run. Severity classes map to response times. Communication templates for internal and external stakeholders are rehearsed before they are needed. Governance includes what happens when things go wrong — not only happy-path approval.

Data subject requests — access, deletion where applicable — are supported through documented procedures for logs and indexes. Retention periods are configured to your policy, not left infinite by default.

Board and executive reporting

Steering summaries translate technical metrics into decision-ready language: what shipped, what risk remains, what next increment costs, what Run observed in production. We do not bury bad evaluation scores in appendices — they appear with remediation plan, same sprint.

Do you write our AI policy?

We inform it with technical reality — what is possible, what controls exist — but policy ownership stays with you. We implement against policy you approve.

Can governance be lighter for internal tools?

Yes, proportionately. Internal-only tools still get logging and access control; external-facing or regulated data keeps the full baseline.

How do you handle regulatory change?

Run includes monitoring for policy updates affecting your use case. Material changes trigger a scoped assessment and, if needed, a change project.

Next step

Start with two weeks.

A fixed-fee discovery gives you a ranked use-case portfolio, a target architecture, a cost model and a build proposal you can take to your board. If we don't find a case worth building, we tell you.