AI Governance

Yes. Most of the AI a company runs is someone else's model inside someone else's tool: the support platform that drafts replies, the CRM that scores leads, the coding assistant, the note-taker on every sales call. Each one sends some of your data, and your customers' data, to a model you didn't choose, and your customers hold you responsible for it all the same. That's why questionnaires ask for subprocessors and training-data commitments, and why a policy alone can't answer them. The model inventory has to cover vendor AI, and each AI vendor needs an assessment: what it sends, where it goes, whether it trains on it, and who signed off.

Probably, and it probably shouldn't. The people who built a system know what it is meant to do, and they stop looking there. An outside reviewer asks the questions nobody inside thinks to ask: who approved this vendor, what happens when this model is wrong, would anyone notice. Those are the questions your customer's security team will ask, so it pays to hear them from us first. What your team keeps is the inventory, the controls and the evidence, so the next questionnaire is theirs to answer.

You can, and it will read fine. What a security reviewer tests is whether it is true: whether you know what AI is running, whether the controls it describes exist, and whether someone checks. A policy that says model output is monitored, when nothing monitors it, fails the review and costs more credibility than no policy at all. The documents are the last step of the work, not the work.

Keep it. A platform like Credo AI, Holistic AI or a compliance tool like Vanta is a system of record: it holds the inventory, maps policy packs to NIST AI RMF, ISO 42001 and SOC 2, and collects evidence. It governs what someone registered in it. We do the parts around it. We find the AI the platform's integrations don't see, the models inside your vendors' tools and the assistants your people signed up for on their own, and get them into the inventory. We decide with you which requirements in a policy pack actually apply, who owns each one, and what "monitored" means for your systems, then build the gateway logging, monitors and circuit breakers that produce the evidence the platform is waiting for. And when the dashboard shows every control green, we spot-check whether that is still true. If you don't have a platform yet, we help you choose one, or tell you that at your size a well-kept register is enough.

Ask what you will have at the end. A good AI governance partner leaves you with documents your customers and auditor will accept, controls running in your systems that back those documents up, and a named owner for the work. Ask who writes the model inventory, whether they can change code or only recommend changes, whether they cover the AI inside your vendors' products, and how you exit if the first phase isn't working.

Evidence over policy. A policy nobody can show is followed doesn't survive a security review. Prioritize a partner who builds the logging, monitoring and ownership behind each document, who works from the US frameworks your customers name (NIST AI RMF, ISO 42001, SOC 2), and who covers third-party AI, because most of the AI a company runs is someone else's model inside someone else's tool.

Usually three things: an AI use policy, an inventory of the models and AI vendors you use (including subprocessors), and a risk register with owners. Behind those come the follow-up questions: whether customer data is used to train models, how you monitor model output over time, what happens when the AI does something unexpected, and who owns AI risk. Each question should point at a document and at a control that's actually running.

It depends on what your customers ask for. NIST AI RMF is a voluntary US framework: it's the common reference for how to structure AI risk work, but there's no certificate. ISO/IEC 42001 is a management-system standard you can be certified against by an accredited certification body. If a customer or RFP asks for a certificate, that means ISO 42001. Either way, the same inventory, risk register and controls do most of the work, so we build them once and map them to both.

On request, yes, as a separately scoped piece of work. The standard engagement leaves you with a question-to-artifact map and the evidence behind each answer, so your team can fill in most questionnaires without us. When a specific customer's questionnaire needs more, we draft the answers with you from the artifacts and attach the evidence. You review and sign them, because the answers are your company's commitments. Where an honest answer today would be "we don't do that yet", we say so, and either build the control or help you word a plan the customer will accept.

A SOC 2 report is an attestation from an independent CPA firm, tested against the AICPA Trust Services Criteria. We don't issue SOC 2 reports. We build the AI-specific controls and the evidence your auditor will test, so AI doesn't become the exception in your next report. SOC 2 also doesn't answer most AI questionnaire questions on its own, which is why customers send them separately.

Senior practitioners who build AI systems in production and have run security and compliance programs. The people who define your protocol are the ones who set up the controls and sit in the questionnaire review with you. There is no handoff to a junior team.

With a free 30-minute call about what your customers and auditors are asking for, and what AI you're running. After the call you get a written read: where you stand, which questions you can already answer, and which need work. If it makes sense to go further, we propose a scoped first phase with a clean exit if it isn't working. It can run as a project on its own, or as part of a fractional CTO and CAIO engagement.