Summary
Picture an employee holding a customer document, trying to decide which tool it can safely go into. Your policy says to protect confidential information. That sentence does not tell them which tools may receive the document, which fields stay restricted, or which account handles a candidate record. They make the call themselves, under deadline pressure, and you find out what they decided after the fact.
An artificial intelligence (AI) policy defines what your company expects. AI operating controls determine what employees and systems can do during real work. Most companies write the first document carefully, then assume it governs behavior on its own. It never does.
The International Organization for Standardization (ISO) defines an AI management system as connected policies, objectives, and processes for responsible AI use. Continuing maintenance is built into the standard. The National Institute of Standards and Technology (NIST) organizes AI risk management around four functions: govern, map, measure, and manage. Both frameworks point to the same operating truth. A policy without controls leaves employees guessing during time-sensitive work, and controls without policy create disconnected restrictions nobody can explain.
Know that a policy sets the position, and controls run the workflow
An AI policy gives your employees a shared understanding of acceptable behavior. It should explain why the company uses AI, which responsibilities remain with people, and which activities need extra care. A good policy stays stable while products, models, and vendors change underneath it. Naming every approved application inside the policy guarantees the policy goes stale within a year.
Operating controls translate that stable language into specific behavior. They can be technical, procedural, or managerial: a blocked connector, a required legal review, a quarterly workflow audit. Match the controls to the use case, since an internal drafting assistant needs far less scrutiny than an agent that can update customer records. The policy creates consistency across the company. The controls create precision inside each workflow.
Use the Policy-Control Architecture as your core thesis
A written position and a working system are not the same accomplishment, and treating them as one is how governance quietly stops functioning. The Policy-Control Architecture keeps them connected on purpose. It has three layers: the position a policy sets, the execution controls carry out, and the connection that proves the two still match.
Layer one: set the position
A durable policy should establish organizational commitments that survive product changes. Employees should use approved tools and accounts, remain responsible for AI-supported work, protect sensitive information, verify AI-generated claims, and keep human accountability over consequential decisions. State that harmful outcomes get reported and production workflows carry assigned ownership too. Leadership retains authority to restrict or stop a workflow when risk changes. These commitments should read the same in marketing, sales, finance, and technology. A policy that names every approved tool or every review threshold has stopped being a policy and started being a maintenance burden.
Layer two: carry out execution
Four groups of controls carry policy language into daily work.
Access and data controls. An approved tool register names the product, business owner, approved users, allowed data classifications, and current status. One product can be approved for public research while staying restricted for customer records. Data controls define which fields a workflow may retrieve, where outputs land, and how long temporary records survive. The minimum necessary principle sets the rule: a workflow gets what its approved purpose requires, not everything technical access happens to expose.
Workflow and review controls. Workflow gates require named evidence, a defined risk classification, and a measurable quality standard before a pilot becomes production. Specify the department, segment, or data classification the approval covers. Human review controls then assign a risk-based level. Full pre-release approval covers legal claims and irreversible actions. Conditional approval triggers on low confidence or unusual value. Sampled review fits mature, stable workflows, and exception-only review fits routine work that has earned it.
Visibility and response controls. Logs should reconstruct what happened: the trigger, sources, actions attempted and completed, and the final outcome. Keep them proportionate, so the log itself does not become another sensitive data store. Escalation paths connect the person who notices a problem with the business, technical, and governance owners who can act on it. A report stuck with one manager never reaches the person who can pause a workflow. Monitoring scorecards attach a response threshold to every measure. A rising correction rate or an unusual permission event should trigger a defined action, not a quiet observation.
Lifecycle controls. Recurring audits check whether the business purpose still holds, whether owners remain active, and whether operating value still exceeds operating cost. Set frequency by risk rather than habit. Change controls require testing and approval before a new model, vendor, or permission set reaches production. A model update can shift quality without ever producing a visible failure. Retirement controls remove access, exported data, and connections completely, because canceling a subscription rarely removes everything a workflow has touched.
Layer three: prove the connection
A policy-to-control map ties the two layers together directly. Each row names a policy requirement, the control that carries it out, the accountable owner, and the evidence proving the control operates. “Employees must use approved tools” connects to the tool register and access permissions, owned by the technology owner, evidenced by quarterly access review. “Consequential outputs require review” connects to the human review matrix, owned by the business owner, evidenced by review records and correction data. Give every important policy line a row. Trace every control back to a policy requirement, a risk decision, or a business need. A map with empty rows is the clearest signal you have that the policy and the operation have separated.
Apply the architecture across your functions
Marketing. Your policy requires accuracy and responsible disclosure. Controls define approved research tools, required sources for factual claims, brand and legal review before publishing, and monthly quality sampling on released content.
Sales. Your policy requires lawful data use and human responsibility for the relationship. Controls define approved qualification triggers, restricted customer fields, confidence thresholds, and human approval before any recommended action reaches a customer.
Employee decisions. Your policy requires fairness, privacy, and human accountability. Controls define job-related criteria, restricted access to candidate information, a prohibition on automatic adverse decisions, and recurring audits of the decisions the workflow supports.
Agents. Your policy requires accountability and controlled autonomy. Controls define a dedicated technical identity, minimum necessary permissions, human approval for higher-impact actions, duplicate-action protection, and a tested emergency shutdown.
Watch for the warning signs the policy and the controls have separated
A few recurring patterns expose the gap before it becomes a real incident. Employees cannot find a current, accessible tool register, so they choose products by familiarity instead of approval. Different managers apply different data rules to the same kind of record, because the policy stayed broad where the workflow needed specifics. Human review depends entirely on personal judgment, with no defined trigger or assigned authority behind it. A pilot quietly becomes production because employees found it useful, with no recorded owner, boundary, or review date attached. Logs capture the final output but not the sources, actions, or approvals behind it, so an incident cannot be reconstructed. Audits confirm that documents exist without ever testing whether permissions, review, or incident response work.
None of these gaps get closed by another policy announcement. Close them by building or repairing the specific control that was supposed to carry the policy into practice.
Use a proportionate model to prevent unnecessary administration
Not every workflow needs the same weight of control. A low-risk internal brainstorming assistant may need an approved account, a prohibition on sensitive information, and annual reassessment. A customer-facing agent needs restricted data access, representative testing, active monitoring, frequent audits, and a tested shutdown method. NIST advises adjusting risk responses to context and established tolerance rather than applying one control set everywhere. Proportionate controls let a low-risk workflow move quickly while reserving deeper scrutiny for the work that carries consequence.
Keep ownership distributed rather than collapsed into one committee. Leadership approves the policy and risk tolerance. Business owners approve the use case. Workflow owners run daily operation. Data stewards, technical owners, reviewers, governance owners, and measurement owners each hold a named piece of the system. ISO/IEC 42001 treats responsible AI as an organization-wide management system, not an isolated technical function, and your ownership model should reflect that from the start.
Run this 60-day plan to connect policy with controls
Days one through 15. Compare the written policy against actual use. Collect the current policy, tool list, vendor records, and incident procedures, then observe how employees handle sensitive information. Record every policy requirement without a supporting control, and every control without clear policy direction.
Days 16 through 30. Prioritize the largest gaps. Classify active use cases by data sensitivity, autonomy, and consequence. Build or update the tool register, data rules, review matrix, and incident process for the highest-risk cases first.
Days 31 through 45. Configure daily execution. Apply the permissions, workflow gates, review routing, and logging the design calls for, then test access restrictions, weak inputs, required approvals, and technical failures directly.
Days 46 through 60. Test the full governance system. Run representative cases through each workflow, including one weak input, one exception, and one simulated incident. Hold the first operating review, confirm the evidence connects every policy requirement to an active control, and decide what continues, changes, or stops.
What you tell them at the end
A policy without controls leaves broad expectations open to interpretation exactly when the stakes are highest. Controls without policy create fragmented restrictions with no shared direction behind them. Neither failure mode looks like a crisis until an incident forces someone to explain what the company does. The honest answer often depends on which manager you ask.
The organizations building durable AI governance in 2026 treat the policy and the controls as one connected system, with evidence proving the connection still holds. The policy states the position. The controls carry it out. The map shows whether the two still agree.
