AI governance implemented
as controls, not policy slides.
Inventory, risk classification, monitoring, and evidence mapped to the frameworks that apply to you — not legal advice, not a certification, just the controls a reviewer can inspect.
Controls you can show
an auditor, not slides.
AI governance only matters if it survives contact with a procurement reviewer, an auditor, or a regulator. We build the inventory, risk classification, and evidence trail that make "we take this seriously" a demonstrable fact instead of a sentence in a pitch deck.
This is not legal advice, and we are not a certification body. We build the technical controls and evidence; your legal counsel retains interpretation and sign-off.
The evidence bar is highest where a wrong decision has regulatory consequences — lending and underwriting and healthcare are the two sectors where we build this most often, usually alongside document AI or RAG systems that already touch sensitive data.
The parts that
actually get checked.
What you
walk away with.
- Data-flow diagrams showing where data moves and who touches it
- Model cards documenting what each model does and its known limits
- A risk register, ranked and reviewed on a cadence you set
- Evaluation reports from ongoing testing, not a one-time snapshot
- Audit logs covering who did what, when
- Incident-response runbooks your team can actually follow
| Control | Evidence artifact | Where it's referenced |
|---|---|---|
| Access control on training/inference data | Access-control policy + logs showing enforcement | SOC 2 CC6, GDPR Art. 32 |
| Model risk classification | Risk register entry per system, reviewed on a set cadence | EU AI Act risk tiers, NIST AI RMF |
| Human oversight on high-impact decisions | Approval-boundary documentation + audit log of overrides | EU AI Act Art. 14, internal change-management policy |
| Data subject rights (access/deletion) | Documented deletion pipeline + request-handling log | UK/EU GDPR |
| Incident detection & response | Incident runbook + post-incident review record | SOC 2 CC7, breach-notification obligations |
This mapping is illustrative of the structure we build, not a substitute for your counsel confirming which specific clauses apply to your business and jurisdiction — see our framework-specific pages for UK and EU clients for the regional detail.
Who owns
what.
Governance stalls when nobody actually owns a control. We assign explicit ownership before building the evidence trail.
| Role | Owns |
|---|---|
| Technical owner (your side) | Describes each AI system's actual behavior and data flow; approves access and process changes |
| Legal counsel (your side) | Interprets which framework clauses apply and signs off on compliance posture — we never make this call for you |
| Dwayo (delivery) | Builds the technical controls, evidence artifacts, and monitoring; maps them to the frameworks you name |
| Incident owner | Named individual who runs the incident-response runbook when something goes wrong — not a shared inbox |
Where relevant,
mapped explicitly.
We map your controls to the frameworks that apply to your business — NIST AI RMF, EU AI Act, UK GDPR/GDPR, HIPAA, and SOC 2 — without claiming certification or giving legal advice. See our dedicated pages for EU AI Act readiness, GDPR AI integration, HIPAA-ready AI development, and SOC 2-ready AI development for the framework-specific detail.
Governance covers
both the same way.
Whether a model comes from a provider or was built in-house, the inventory, risk classification, and monitoring apply the same way. What differs is the evidence available — a vendor's documentation and SLAs versus what you can generate yourselves — and we account for that gap explicitly rather than assuming vendor coverage you don't actually have.
Timeline
and stakeholders.
We typically start with the inventory and risk classification, then build out evidence in priority order based on your nearest procurement or audit deadline. Your side needs a technical owner who can describe each system, and someone with authority to approve access and process changes. Legal counsel reviews the evidence for sign-off — we don't make that call for you.
No sales pitch,
just how we work.
Every deliverable is something a reviewer can actually inspect.
Not legal advice, not a certification body — we say so plainly.
We know what the evidence has to look like because we build the systems it describes.
You own the inventory, registers, and runbooks at completion.
Before you
book a call.
Is this legal advice?
No. We build the technical controls and evidence that your legal counsel needs to assess compliance. Legal interpretation and sign-off stay with your counsel.
Do you certify us as compliant?
No — we are not a certification body for any framework we reference. We map your controls to the relevant requirements and build the evidence those frameworks ask for.
What if we use third-party models we did not build?
Governance still applies the same way — the difference is in what evidence you can get from the vendor versus generate yourselves.
What do we actually walk away with?
Data-flow diagrams, model cards, a risk register, evaluation reports, audit logs, and incident-response runbooks — artifacts a reviewer actually asks for.
Who on our side needs to be involved?
A technical owner who can describe each system's actual behavior and data flow, and legal counsel to interpret which clauses apply and sign off. We build the controls and evidence; we don't substitute for either role.
What happens when an incident actually occurs?
A named incident owner runs a documented runbook — not an ad-hoc scramble or a shared inbox. The runbook is tested before you need it, and every incident produces a post-incident review record that feeds back into the risk register.
Tell us what
review you're preparing for.
Book a 30-minute call — we'll tell you honestly what evidence you're missing.