What is an AI governance framework and which one should we use? +
An AI governance framework is a written set of risk controls, deliverables, and review gates that an AI system is held to over its lifecycle. The three that matter for most teams in 2026 are the EU AI Act (binding regulation across the EU, risk-tier obligations escalating through Limited / High / Unacceptable categories), NIST AI RMF 1.0 (the US voluntary framework — Govern / Map / Measure / Manage functions), and ISO/IEC 42001:2023 (the international standard, AI management system, certifiable). For most shipped AI systems we audit, the answer is "all three at once," because the engineering artefacts (model card, eval suite, audit log, DPIA-equivalent, incident runbook) are largely the same — only the framework labels differ. We write the artefact once and crosswalk it to whichever framework your buyer or regulator cares about. Most engagements start with a
governance audit via consulting — a 1-2 week assessment that maps your AI inventory against EU AI Act, NIST RMF, and ISO 42001 obligations before any remediation. Verticals with high governance load:
education data governance (FERPA + COPPA) in addition to the standard healthcare / fintech / insurance / legal set.
Will you get our AI system ISO 42001 certified? +
No — and we say that openly. We are not a certified ISO 42001 audit body and we do not hold ISO 42001 lead-auditor credentials. What we do is the engineering preparation: we ship the AI management system artefacts a certified auditor will ask for (risk assessment, model cards, eval suite, audit log, incident-response runbook, supplier register, internal audit programme). When you're ready, a certified body (BSI, TÜV, DNV, others) runs the actual ISO 42001 certification audit. The same applies to SOC 2, ISO 27001, and HITRUST — we prep the system for the audit; someone else conducts it. If you need a one-stop firm that does both prep and certification, hire a Big-4. We're cheaper, faster, and we ship code — but we're not the auditor.
What does an AI audit actually deliver in week 1? +
Five artefacts. (1) A risk-tier call per use case, mapped to EU AI Act categories with written reasoning. (2) An eval-coverage scorecard naming what's covered, what's missing, and what regression cases would close the gap. (3) An audit-log + lineage gap list against Article 12 / NIST Manage 4.1 / ISO Annex A.8. (4) A red-team + prompt-injection report covering OWASP LLM Top 10 with severity-ranked findings. (5) A framework crosswalk + 30-60-90 remediation roadmap that names PRs, cost bands, and a kill-point on each phase. AI audit services that stop at a slide deck are the marketing version; the AI compliance audit we run leaves you with a document an engineering team can ship from.
How is AI red teaming different from a regular pen-test? +
A regular pen-test exercises the network, the API, the auth layer — classic infosec. AI red teaming (LLM red teaming specifically) exercises the model layer: prompt injection (direct + indirect), data exfil + sensitive-information disclosure, jailbreak chains, tool-output poisoning, system-prompt leakage, supply-chain attacks on embedding models and training data. The OWASP LLM Top 10 (2025) is the standard reference. We run both — the network pen-test boundary is well-served by traditional infosec firms, but they don't ship prompt-injection regression cases into a nightly eval run. We do. AI security assessment work without an LLM-layer red-team isn't an AI security audit; it's a network audit with an AI label.
Do you cover the EU AI Act risk-tier obligations? +
Yes — as an applied framework we map your system to, not as a certification we issue. We classify each use case (Unacceptable / High / Limited / Minimal under Annex III) with written reasoning, then walk you through the Title III obligations the classification triggers: Article 12 logging, Article 13 transparency, Article 15 accuracy + robustness + cybersecurity, Article 25 importer / distributor responsibilities, Article 47 conformity declaration, Article 62 serious-incident reporting. The output is an engineering checklist plus a written declaration template. The certified conformity assessment (for High-risk systems on the standalone list) is then run by a notified body — not us. EU AI Act compliance prep, not EU AI Act certification.
What's the difference between you and Credo AI / OneTrust / Holistic AI? +
Credo AI, OneTrust, and Holistic AI are AI governance platforms — SaaS dashboards that help large GRC teams inventory AI systems, run policy templates, and track risk across many models. They're well-suited for regulated enterprises with a multi-million-dollar GRC budget and a platform-ops team to configure them. We're not a platform. We're the engineering service that ships the underlying artefacts a platform would track — eval suites, audit logs, model cards, remediation PRs. Many teams use both: the platform for board-level reporting, us for the engineering work the platform needs to point at. We don't compete with them; we operationalize them. When the platform fit isn't right, we're the lighter-weight alternative — same engineering output, no annual platform fee.
How do you handle third-party / vendor AI risk? +
We start with an inventory of every external AI call your system makes — base model, embedding model, vector DB, observability, eval platform, moderation API, any plug-in or function-calling target. For each vendor we score BAA / DPA posture, retention defaults, sub-processor list, named-jurisdiction processing, and model-card transparency. The output is a supplier register an auditor can read and a gap list of contracts to renegotiate. AI vendor risk assessment work that stops at "we use OpenAI" misses the four to six other vendors typically in the pipeline; we surface them all.
Can you audit a system you didn't build? +
Yes — about half of our governance engagements are on systems built by other teams or vendors. What we ask for: a system architecture sketch (we can build one with you in a 90-min session if none exists), read-access to the eval set and logging architecture, named owners for the use cases in scope, and a willing engineering counterpart to run remediation PRs with us afterwards. AI security audit work without engineering remediation rarely closes the gap, so we prefer engagements where the remediation pilot can ladder out of the audit — but we'll run the audit standalone if you just need the gap report for a board or a regulator's pre-engagement query.
Do you do bias audits at academic / regulator standard? +
No — and we recommend specialists when that's the bar. We ship operator-grade AI bias audit work: subgroup-performance breakdowns on a versioned eval set, disparate-impact metrics on classification systems, named limits in the model card. That's useful for AI compliance review and for surfacing issues before production. It is not equivalent to the peer-reviewed statistical work done by academic groups or specialist algorithmic auditors like babl.ai or ORCAA, who hold credentials and methodology we don't. When the engagement requires regulator-facing or peer-review-grade bias evidence, we refer to those specialists openly. Responsible AI work means knowing what you're qualified to ship and what you aren't.