Managing the Responsible Use of AI: A Practical Guide for Managers

The client update that looked fine

A manager asks AI to turn a page of rough operational notes into a clean client update. The draft comes back looking excellent. The writing is clear, the structure is better than the original notes, and the manager checks the tone, fixes one sentence and sends the draft to the account lead. Ten days later, the client questions one of the numbers, and nobody can find the figure in the source data. The AI had taken an ambiguous sentence in the notes, made a plausible inference and written the result with enough confidence that nobody stopped to question it.

This is the kind of AI mistake I worry about more than the spectacular examples that make headlines. Nothing obviously broke. The AI did not produce nonsense, and nobody ignored a warning flashing across the screen. The output looked good enough that normal work simply continued, and that is where responsible AI becomes a management problem rather than a policy problem.

Most organizations now have some version of four rules: use approved AI tools, do not enter sensitive information, check AI-generated output, and humans remain accountable. All sensible. The trouble starts at 2:17 p.m. on a busy Wednesday, when someone has a customer deadline, a plausible AI answer and seven other things to finish. Who checks, and against what? Which information should never have entered the AI system in the first place? What happens when the employee is not sure the task is allowed, which AI-assisted decisions need a second person, what gets documented, and who needs to know if something goes wrong?

A policy tells people the boundaries. Management controls turn those boundaries into behavior, and that second part is what this guide covers.

Responsible AI is not “review everything”

One of the easiest responses to AI risk is to say that a human should review all AI output. It sounds safe, and in practice the rule becomes impossible quickly. An employee reorganizes their own meeting notes with Copilot. Someone rewrites three headings. A manager asks AI for ten questions to consider before a workshop. A finance analyst uses AI to explain a material variance, and an HR team uses it to summarize candidate information. Should those all receive the same review? No. If every interaction demands the highest level of control, employees either stop using AI or start treating the control as paperwork.

The goal is appropriate oversight, not maximum oversight. NIST’s AI Risk Management Framework takes a similar view. It is voluntary, and it organizes risk work around four functions, Govern, Map, Measure and Manage, rather than around a single blanket control.^[1] Its Generative AI Profile, released in July 2024, covers risks that range from confabulation (fabricated output) to privacy, information security, intellectual property, harmful bias and human-AI configuration, which includes problems such as overreliance.^[2]

That is the first thing I would change in how most teams talk about responsible AI. Instead of asking how closely AI should be monitored, ask what can go wrong in this particular workflow, and what is the lightest control that catches the problem before harm occurs. It is a much more useful management question, and the rest of this guide builds on it.

Start before the prompt: the Responsible AI Control Loop

Checking the output is only the middle of the story. Suppose an HR manager pastes confidential employee information into an unapproved public AI tool, and the tool produces a perfectly accurate summary. Reviewing the output does not fix the problem, because the risk occurred at the input. Or suppose a salesperson connects an AI agent to email and lets it send messages without approval. Every draft may be accurate, and the bigger question is whether the system should have had that authority in the first place. Responsible AI has to cover the whole workflow: what enters, what AI does, what leaves, who decides and what happens afterward.

I use six questions for that, and I call the set the Responsible AI Control Loop. Before an AI-assisted workflow becomes normal, answer them in order.

The first question is whether AI is allowed here. Some work is fine for AI assistance, some needs specialist approval, and some uses are restricted by organizational policy, contracts, industry requirements or law. Employees should not have to interpret all of that from scratch. The second is what information can enter: customer data, employee data, confidential financials, contract terms, source code, or public information only. The answer depends on the tool, its approved enterprise configuration, your policies and the requirements that apply to you.

The third question is what AI can do, whether that is summarize, draft, recommend, rank, send or approve. The jump from suggesting to acting is often where the risk changes materially. The fourth is what the person still owns. Who decides whether the answer is correct, who owns the recommendation, and who stays accountable when AI contributed to the work? Write that down.

The fifth is what the person checks against, and it is where most review rules go vague. “The manager reviews the output” does not say against what. A source document, the general ledger, approved pricing, the full candidate pool, a live operations dashboard and a policy are all different checks. Human oversight only works when the reviewer knows what evidence should beat the AI answer. The sixth is what happens when something goes wrong: where uncertainty gets escalated, what gets logged, who can pause the workflow, whether information already sent needs correcting, and whether someone should look into the underlying process.

Step 1: Decide whether it is a Go, Ask or Stop use

Before deciding how much review a task needs, decide whether the use belongs in the workflow at all. I give employees three simple states.

Ask is the state that matters most, because organizations often give employees only two choices, allowed or forbidden, and real work contains a large middle. Maybe sensitive information is involved, or AI is shaping a consequential recommendation, or an employee wants to connect a new data source, or nobody knows whether an existing policy covers the task. Give that middle somewhere to go.

Responsible AI guidance is not legal advice, and requirements differ by jurisdiction, industry, system and use case. The EU AI Act shows why. Its transparency rules in Article 50 apply from August 2, 2026, while the date for the Annex III high-risk rules was moved to December 2, 2027 by the Digital Omnibus.^[8] Managers do not need to memorize legislation. They need to know where the Ask path leads.

Step 2: Match oversight to consequence

Once a use is allowed, decide how much review the work needs. I use three levels, and I call the lowest one a spot-check rather than autonomous, because low oversight does not mean unlimited autonomy.

If you are deciding whether a task should involve AI at all, the fit test in our guide to when not to use AI at work is a good companion to the three levels above.

Accuracy is only one risk

Responsible AI often gets reduced to checking for hallucinations. Accuracy matters. McKinsey’s March 2025 global survey, fielded in July 2024 with 1,491 respondents, found that 47% said their organizations had experienced at least one consequence from generative AI, with inaccuracy, cybersecurity and intellectual property infringement the most commonly cited causes. Only 27% said employees review all generative AI content before it is used.^[3] Newer editions of that survey exist, and I use these figures because they are the ones I could confirm in the report text.

So before designing a control, ask which kind of failure you are trying to catch. Accuracy asks whether AI could invent, distort or omit something important. Privacy asks whether employees are sharing personal, sensitive or confidential information appropriately, and security asks whether the system, a connector or an agent could expose information or take an action nobody intended. Fairness asks whether a consequential process could disadvantage people or groups. Intellectual property asks whether protected material or ownership questions need specialist review.

Explainability asks whether the person responsible can say how a recommendation was reached. Accountability asks whether a named human is still responsible, or whether everyone has quietly started accepting “the AI said so” as an answer. Trust asks whether you would be comfortable explaining AI’s role to the person affected by the output. You do not need an eight-page risk assessment every time someone asks Copilot to format a table. For consequential workflows, these are the questions to work through.

A useful control catches the right failure

Say four teams each report that they have human review. They may mean completely different things. A marketing manager checks an AI-generated product post against the approved product page. A finance manager checks AI-generated variance commentary against the ledger. An HR manager checks an AI-assisted candidate summary against the underlying application material and whatever hiring controls the organization requires, and a procurement lead checks a contract summary against the actual contract before relying on it. All four involve a person reviewing AI output, yet the control in each case is something more specific than human review.

I would ask every team to complete those three columns for its highest-consequence AI workflows. If the middle column just says that a human reviews, keep going and ask what the human actually owns.

When “human in the loop” becomes theater

There is a trap here. Organizations add a human approval step and assume the risk is managed. But if the person approving is handed 60 AI-generated cases an hour, cannot see the source material, or assumes the AI is usually right, the human turns into a rubber stamp. That is not meaningful oversight. Our guide to writing human-in-the-loop guidelines goes deeper on how to word the review step.

The OECD’s Due Diligence Guidance for Responsible AI, published in February 2026, puts the weight on ongoing management rather than one-time sign-off.^[4] It is a voluntary framework that works through six steps: embedding responsible conduct in policies and management systems, identifying and assessing adverse impacts, ceasing, preventing or mitigating them, tracking implementation and results, communicating what is being done, and providing for remediation where appropriate.^[5]

That is a more useful way to think about oversight, because a control is only useful if the person can reasonably perform it. Does the reviewer have enough time, and do they have the source? Do they know what failure looks like, and do they have the authority to reject the AI output? Will they be penalized for slowing the process down? If the answer to any of those is no, adding “human approval required” to a policy may create comfort without much control.

Agents make authority more important than prompting

This matters even more as organizations move from AI that answers questions to AI that takes actions. A chatbot drafts. An agent may draft, open systems, update records, send messages or start another step. The management question changes from whether the output is accurate to what authority the system was given.

For an agentic workflow, I would define six things explicitly.

• Read: what information the agent can access.
• Write: what records the agent can change.
• Act: what external actions the agent can take.
• Spend: whether the agent can trigger a financial commitment.
• Send: whether the agent can communicate externally.
• Escalate: which conditions force the agent back to a person.

This does not mean every agent needs a governance committee. A scheduling agent and an agent that changes customer pricing do not deserve the same process.

Give employees an escalation path they can remember

A policy that says to contact the appropriate stakeholder if uncertain is barely an escalation path. Which stakeholder? If an employee has to search SharePoint for a governance deck before knowing who to ask, many will make the decision themselves. I give teams something much simpler, a short list that maps the kind of question to the place it goes.

• Tool or access question: IT or Security.
• Personal or sensitive data question: Privacy.
• Employment decision: HR and Legal.
• Contract or regulatory question: Legal or Compliance.
• Customer commitment or money: the named business owner.
• Unexpected AI behavior: AI governance or the designated operational owner.

The exact routes will differ by company. What matters is that people know where uncertainty goes. For a smaller organization without dedicated functions, name the actual person. If “Compliance” is one individual, write that person’s role into the process instead of the department name.

Replace the weekly score with a control check

I would not score oversight at all. A team does not need to know that its oversight rhythm is a 7. It needs to know whether a control failed. For a high-consequence workflow, I would ask four questions weekly or monthly, depending on volume.

Near-misses deserve more attention than they usually get. Suppose AI invents a customer number and the manager catches it before the email leaves the company. That is not simply a review that worked. Log the near-miss and ask why the model had enough ambiguity to invent the number, whether the source material could be improved, whether the instructions should prohibit inference on numerical fields, whether numbers should come straight from an approved data source, and whether the same failure can happen in another workflow.

The aim is not for reviewers to catch the same error forever. The aim is to learn enough from the catches that the workflow produces fewer of them, which is why I like the OECD’s emphasis on tracking whether controls are effective.^[5] A near-miss is free information about where your process is weak, so use it.

Keep a register, but not for every prompt

The mistake would be logging every AI interaction in the company, because nobody is going to maintain that. Log the uses where accountability matters enough that someone may reasonably ask later what happened, which AI system was involved, who reviewed the outcome, what evidence they used and whether anything was corrected.

For a small team, start with those columns and nothing more. The purpose of the register is not to prove the governance team is busy. It is to create traceability where traceability matters. ISO/IEC 42001 takes the same management-system view at a larger scale, setting requirements for establishing, implementing, maintaining and continually improving an AI management system.^[7] ISO also published ISO/IEC 42005 in May 2025 as guidance for AI system impact assessment.^[6] You do not need certification to borrow the operating principle: governance should be a system, not a memo.

Train managers on scenarios, not principles

One reason responsible AI breaks down is that the people closest to the work have the least usable guidance. A manager receives a policy that explains fairness, transparency, privacy, accountability and security, all of it important. Then on Thursday an employee asks whether they can upload customer interview transcripts into Copilot, and the manager has no idea. The training never reached the level of the work.

I would train managers with scenarios. Can AI draft this customer response, and which tool can receive this information? Can AI summarize this employee feedback, or rank these candidates? Can an agent send this message automatically? What if AI gives a recommendation but cannot say where it came from, or a customer asks whether AI was involved? Those are management questions, and the training needs enough realism that employees recognize the boundary when they meet it.

If the program works, an employee should be able to answer three things without opening the policy: which AI tools they may use, what information they may give those tools, and when they need another person before the output moves forward. Then add role-specific guidance. A marketer should know the rules on public claims, copyrighted material and customer information. A finance employee should know which figures require source verification and which systems count as authoritative. An HR employee should understand the stronger controls around personal information and consequential people processes, and a manager should know when an AI-assisted people, customer or financial decision needs escalation. Generic principles sit above the work, and role-specific examples connect them to it. You need both.

Not the department of “no,” not the same as compliance, and who owns it

Governance gets a bad reputation when every unusual AI idea is met with “we need to check with Legal,” and nobody hears back for six weeks. Employees then either stop experimenting or build workflows quietly, which is not safer. A good model makes the safe path easier to find, with four answers available: yes, with these conditions; yes, but this needs review; not with that data, so use this approved path; or not for this decision. Clear boundaries can increase responsible experimentation because employees no longer have to guess. The OECD guidance frames the job the same way, as supporting enterprises while they address adverse impacts, not as a reason to stop.^[4]

Responsible AI and legal compliance overlap, but they are not identical. A use can comply with current law and still be a poor decision for your customers or workforce. Another can be ethically reasonable and still require specific legal controls where you operate. NIST’s framework and the OECD guidance are voluntary, ISO/IEC 42001 is a management-system standard, and the EU AI Act creates legal obligations, as do your own contracts, industry requirements, privacy laws and employment laws. Do not give managers a standards lecture. Make sure the people designing your governance know which requirements apply, then translate them into usable employee guidance.

Who owns all this? At an enterprise level, responsibility is shared across technology, security, privacy, legal, risk, HR and business leadership. At the workflow level I want a simpler answer: the person accountable for the business outcome remains accountable for how AI participates in producing it. That does not turn the manager into a privacy lawyer. Specialists provide the rules and the escalation path, and the business owner applies those controls in the work. A marketing director who approves an AI-assisted campaign is still accountable for it, a finance leader who signs off on AI-assisted analysis cannot defend a bad number by pointing at Copilot, and feedback a manager delivers to an employee remains the manager’s feedback.

How you know responsible AI management is working

Do not count how many people signed the policy or how many rows sit in the register, and do not congratulate yourself because nobody reported an incident. No reported incidents can mean excellent controls. It can also mean employees do not know what counts as an incident, or are afraid to report one. I use the same Use, Persistence and Impact lens we apply to AI adoption generally, but pointed at the controls.

Use asks whether the controls are actually happening: whether employees use approved tools, whether required reviews occur and whether people use the escalation path. Persistence asks whether those behaviors continue after the rollout campaign ends and survive busy periods, since a practice that works only while Compliance is sending reminders is not embedded yet. Impact asks whether the controls are catching meaningful issues, whether the same near-misses are decreasing, whether serious issues are caught earlier, and whether governance is helping teams use AI with confidence instead of pushing experimentation underground.

On the leadership dashboard, I would replace a figure like “98% policy acknowledgement” with five things.

• AI use: which approved tools and higher-consequence workflows are actually in use.
• Control: what share of workflows that require review completed that review.
• Incidents and near-misses: what happened and where in the process the issue was caught. A rise in near-miss reports early on may be a good sign if people are learning what to report.
• Recurring failure modes: whether the same inaccuracies, privacy questions or approval failures keep repeating.
• Remediation: which workflow, policy, training or technical control changed because of what you learned.

That last line is the one I care about most, because governance should learn.

A 30-day starting plan

If an organization has an AI policy but little operational oversight, I would not start by redesigning the whole governance system. Pick three real workflows: one customer-facing, one internal decision-making workflow, and one involving data that deserves stronger protection. Then work through four weeks.

That is a better start than writing version 2.0 of a policy nobody can remember.

The question I would leave managers with

Responsible AI can sound enormous: regulation, ethics, bias, privacy, security, governance frameworks and impact assessments. Most managers do not need to become experts in all of it. They need enough clarity to manage the AI touching their work. So when AI enters a workflow, I would ask what can go wrong here, who would be affected, and what needs to be true before I am comfortable letting this move forward. Then make the answer operational: which tool, which data, which human, which source, which approval and which escalation.

The safest organization is not the one with the longest AI policy. It is the one where, on an ordinary busy Tuesday, the person using AI knows what they are allowed to do, what they still own, what they need to check and where to go when they are not sure.

Sana Mian, Co-Founder of Future Factors AI

Sana is an AI educator and learning designer specialising in making complex ideas stick for non-technical professionals. She has trained 2,000+ learners across corporate teams, bootcamps, and keynote stages. Future Factors offers AI Bootcamps, Corporate Workshops, and Speaking & Consulting for businesses ready to adopt AI without the overwhelm.

More about Sana →