A policy says what should happen. A control is the thing that actually happens, on a schedule, with a record. The next stage of AI governance for most companies is closing the distance between the two.
The test is simple. Pick one line from your AI policy — for example, "all AI use cases are risk assessed before deployment." Then ask: who performs that, when, using what method, where is the output stored, and can you show the last five? If any part of that has no answer, you have a policy statement without a control.
Why Policies Alone Stop Working
Policies were the right first step. They set direction quickly and gave legal and leadership something to point at. They stop being enough for three reasons.
They cannot be evidenced. Customers, auditors, and procurement teams increasingly ask for records, not the policy document.
They do not survive change. AI systems change when models, prompts, data, or vendors change. A static document does not track that; a control with a trigger does.
They are written for a reader who does not exist. The person deploying an AI feature inside a business tool rarely reads the AI policy. A required approval step in their workflow reaches them; a PDF does not.
What Turns a Policy Line Into a Control
Every working control has five parts:
- A trigger — what starts it (a new use case, a model change, a quarterly review, an incident).
- An owner — a named role, not a committee.
- A method — the defined steps, template, or checklist used.
- A decision — what outcome the control produces (approve, reject, escalate, remediate).
- A record — where the evidence lives and how long it is kept.
If you write those five columns next to each policy statement, the gaps become obvious within an hour.
The Controls Most Companies Need First
Intake and approval
A single route by which a new AI use case gets registered and approved, including vendor features enabled inside existing tools. Without intake, every other control has an incomplete population.
AI inventory maintenance
The inventory is only useful if something keeps it current. Tie updates to the intake control and to a periodic review.
Risk assessment
A repeatable method applied to systems that matter, producing a documented result. See the AI risk assessment guide for a structure you can adapt.
Human oversight
Defined review points, defined reviewer information, and defined authority to reject. Human-in-the-loop oversight covers the design choices.
Change management
A trigger that re-opens assessment when the model, prompt, dataset, vendor, or purpose changes materially.
Vendor and third-party review
Documented questions on data use, model changes, logging, subprocessors, and incident notification, answered before purchase and revisited at renewal.
Monitoring and incident handling
Thresholds, an escalation route, and a record of what happened and what changed afterwards.
Internal audit and management review
Someone independent checks that the controls above ran, and leadership reviews the results and decides what to change. This is where ISO/IEC 42001 and other management-system standards are genuinely useful — the pattern is proven and auditors recognize it.
For method and terminology on risk, the NIST AI Risk Management Framework is a widely used voluntary reference. Where legal obligations may apply, the EU AI Act depends on your role and the system, and should be assessed against your own circumstances.
How To Sequence the Work
Trying to stand up twelve controls at once usually produces twelve half-controls. A workable order:
- Intake and inventory. You cannot govern what you cannot list. A shadow AI review helps find what intake missed.
- Risk assessment for the systems that matter. Not everything. Start with systems affecting people, money, safety, or regulated processes.
- Oversight and approval for those systems.
- Change and vendor controls, because these are what break the first two over time.
- Monitoring and incidents.
- Internal audit and management review, once there is something to audit.
Companies already running ISO 9001, ISO 13485, or ISO 27001 have an advantage: the intake, change, audit, and review machinery exists. The work is extending it, not rebuilding it — for example by updating an existing ISMS for AI risks.
Signs Your Controls Are Real
- You can produce the last three completed risk assessments without asking around.
- Someone has rejected or paused an AI use case, and there is a record of it.
- A model change triggered a review without anyone remembering to start one.
- Your AI inventory matches what procurement and IT actually pay for.
- An internal audit of AI scope has produced findings, and those findings were closed.
Controls that never produce a "no" are usually not being applied.
Where Specialized Expertise Helps
Designing controls that are strong enough to be credible and light enough to be used is a practical skill. It is usually learned by doing it across several organizations.
ElevateQCS helps companies find, vet, and engage specialized quality, compliance, regulatory, and technical experts — including people who have built AI management systems, run AI risk assessments, and prepared organizations for audits. You tell us the requirement. We identify and vet relevant professionals. You review them and decide who to engage directly, or ask ElevateQCS to manage the engagement.
If you are hiring for this work, how to hire an AI governance expert and how to hire an ISO 42001 consultant cover what to look for. When you are ready, tell us what you need.
This article is educational and is not legal advice. ElevateQCS is an independent expert sourcing and engagement company — not a certification body, auditor, or law firm.
Frequently Asked Questions
What is the difference between an AI policy and an AI control?
A policy states an intention or rule. A control is the operating step that carries it out — with a trigger, an owner, a method, a decision, and a record. Auditors and customers generally ask about controls and their evidence.
Why isn't an AI policy enough?
Because it cannot be evidenced on its own, it does not react to changes in models or vendors, and it rarely reaches the people actually enabling AI features in day-to-day tools.
What AI controls should we implement first?
Intake and approval for new AI use cases, a maintained inventory, and documented risk assessment for the systems that affect people, money, safety, or regulated processes.
How do we document AI controls?
Record the trigger, owner, method, decision, and evidence location for each control, then keep the outputs — assessments, approvals, review records, test results, incident records — in a place that can be produced on request.
What evidence do auditors ask for in AI governance?
Commonly an AI inventory, risk assessments, approval and oversight records, change history, vendor documentation, training records, incident records, internal audit results, and management review minutes.
Can we use ISO 42001 as a control framework?
Yes. ISO/IEC 42001 sets out management-system requirements an organization can build against and, if it chooses, be certified against by an independent certification body. Certification is voluntary.
How often should AI controls be reviewed?
Set a periodic cycle — many organizations use annual or semi-annual — and add event triggers for model changes, vendor changes, new use cases, incidents, and audit findings.
Who should own AI controls?
Each control should have a named role as owner. Ownership is commonly split between the business owner of the system, a risk or compliance function, and security for technical controls, under an executive sponsor.
Do small companies need formal AI controls?
The controls can be proportionate. A small company may run intake, risk assessment, and review as a short documented process rather than a large program — but the record still needs to exist.
When should we bring in outside help?
When you are designing the control set for the first time, when an assessment needs to be independent, or when an audit or customer requirement has exposed gaps you do not have the in-house experience to close.
Sources
These references provide standards, regulatory text, or background context. They do not independently validate every recommendation in this article. Linking does not imply endorsement. Standards may require purchase; refer to the publisher for the current text.
