AI Accountability: How People Should Steer AI Systems
Learn why AI accountability must stay with people, when to use agents instead of software, and how companies can prepare teams to supervise AI responsibly.
Who Should Steer AI When It Starts Doing the Work?
Companies are shifting more work to AI, but handing over a task doesn't hand over responsibility. When an AI agent sends a customer email, updates a record, or recommends a decision, it can still create real consequences for the business. Someone has to decide what it's allowed to do, check whether it handled the job correctly, and step in when it didn't.
That was the central point Daniel Dines, founder and CEO of UiPath, made at the company's FUSION event in Dubai on November 2, 2026. His warning is worth hearing because it cuts through a common idea: that more capable AI automatically means less human involvement. The opposite is often true. As autonomy grows, so does the need for clear ownership.
This article turns that argument into a practical framework. It explains what it means to steer AI, where accountability belongs, which kinds of work still belong in conventional software, and how teams can adjust without abandoning junior employees or building everything around narrow specialist roles.
What does it mean for people to steer AI?
Steering AI means setting what a system is allowed to do, what information it can use, what outcomes are acceptable, and when a person must intervene. It's not the same as watching a dashboard or rubber-stamping every output. It's a management responsibility that needs to be built into how the work runs.
At FUSION, Dines told customers that companies will delegate more work to AI. That raises the value of employee judgment and initiative. In practice, people spend less time executing repeatable steps and more time defining the task, supplying context, reviewing exceptions, and deciding what to do when the system hits a situation its designers didn't anticipate.
Why broad context matters
An AI system can process a lot of information and still miss the context that determines what a company should do. Dines used lawyers as an example: an agent might learn legal material from books, but it may not know how that law applies inside a specific company.
You see the same gap in other roles. A support agent might know the refund policy, but not why a long-standing customer gets an exception. A finance system might recognize an unusual invoice, but not whether the supplier relationship makes the deviation legitimate. Often the missing piece isn't more data - it's the organisation's priorities, commitments, and operating history.
That's why swapping out narrow specialists for people who understand the wider system isn't just a staffing tweak. Someone has to connect policy, customers, risk, operations, and the consequences of a decision. The more departments share automated work, the harder it is to optimize one step without breaking another.
Steering is a designed control, not a vague principle
If you want oversight that actually works, set the boundaries before the AI system goes live:
- Scope: Which tasks can it perform, and which are out of bounds?
- Authority: Can it recommend, prepare, or execute an action?
- Context: What business rules and records must it use?
- Escalation: Which exceptions require a person, and who receives them?
- Evidence: What record will show what the system did and why?
These controls should track risk. Summarizing internal meeting notes shouldn't need the same approval path as changing a customer account or making a financial commitment. If oversight ignores risk, you either slow everything down or turn it into paperwork.
Who is accountable when an AI agent acts?
The company remains accountable for decisions made through its systems. An AI agent doesn't inherit legal, commercial, or ethical responsibility just because it carried out an action. People choose the system, set its permissions, connect it to company data, and decide whether its outputs can be used.
Dines described accountability as one of AI's limits, along with the fact that AI doesn't "learn on the job" the way people do and that its outputs aren't exact. He also pointed out that even an email to a customer can commit a company. The takeaway is simple: if an action can affect a customer, employee, supplier, or regulator, someone needs to own it.
Assign ownership across the workflow
One practical approach is to name owners at three levels:
- Business owner: Defines the outcome, acceptable risk, and task boundaries.
- Technical owner: Maintains the model, integrations, permissions, testing, and operational monitoring.
- Decision owner: Handles escalations and is authorized to approve, reverse, or explain consequential actions.
In smaller teams, one person may cover multiple roles. The key is that each responsibility is explicit. Saying "the AI team owns it" isn't enough if that team can't decide what a customer should be told or whether a transaction should proceed.
Make accountability operational
An accountability policy only helps if teams can use it during normal work. For each AI-enabled process, document what actions are permitted, what triggers escalation, and how a person can stop or reverse an action. Keep records of inputs, outputs, approvals, and changes to the system - at a level that matches the risk.
Then test the failure path, not just the happy path. What happens if the agent gets incomplete information? What if it repeats an action, gives inconsistent answers, or makes a promise outside policy? Who sees the alert, and can they resolve it before the customer is affected?
These questions matter even more when an agent can act across connected systems. A mistake in a draft is usually easier to contain than a mistake that has already updated a record, issued a refund, or created a commitment. As an AI system's authority grows, the control and recovery plan should get stronger too.
Human oversight doesn't mean a person must review every low-risk output. It means the organisation decides, deliberately, which actions can run unattended, which require approval, and how it will respond when something goes wrong. That's governance work - not a switch you flip.
When should a company use AI instead of software?
A company shouldn't use AI just because AI can do the job. Dines made the point directly at FUSION: if conventional software can handle a task reliably, it may be the better choice. Traditional software can be tested against expected inputs and should return the same result under the same conditions. That predictability matters in workflows where consistency matters more than interpretation.
AI is more useful when the work involves ambiguity: interpreting unstructured information, producing a first draft, extracting meaning from varied documents, or helping someone navigate a large set of options. Even then, the decision should be based on the whole workflow - not on a demo of what the model can do.
Use a task-fit test
Before adding an AI component, ask four questions:
- Is the input predictable? If inputs and rules are structured, ordinary software may be enough.
- Does the work require interpretation? AI can help when people currently reconcile varied language or incomplete context.
- What's the cost of being wrong? A high-impact mistake calls for tighter review, narrower permissions, or a non-AI approach.
- Can the result be verified? If no one can check whether the output is correct, it's hard to deploy it responsibly.
This isn't an anti-AI argument. It's a way to keep AI out of places where variability adds risk but brings little value. A stable calculation doesn't become better just because a model can generate it. A workflow with clear rules may be cheaper to maintain as software than as an agent that needs ongoing monitoring and retesting.
Let AI help build deterministic tools
Dines suggested another split: AI can help generate software, and people can review and test that software before it runs. He talked about using AI while writing his book, The Work That Remains, and said he rarely edited the text himself. He also said, "nobody is ever touching the code again."
That line is best read as a signal of how quickly coding workflows may change - not as a safe rule for production systems. Code generated by AI still needs testing, security review, maintenance, and an owner who understands what happens when dependencies, data, or requirements shift. Passing one test suite doesn't guarantee the code will behave correctly under conditions the tests didn't cover.
A sensible pattern is to use AI to speed up implementation, then rely on normal engineering controls to validate and operate the result. In a low-risk internal prototype, the review burden may be lighter. In software that handles payments, personal data, or customer commitments, the bar should be much higher. The goal isn't to keep every manual step - it's to keep evidence and responsibility aligned with impact.
How can companies prepare people for AI-led work?
Preparing for AI doesn't mean waiting for a new job title or retraining everyone to become a machine-learning engineer. Most organisations need employees who can understand a process end to end, use tools critically, and recognize when an automated result doesn't fit the situation.
Dines argued that education systems shaped by the industrial revolution were designed to produce workers who follow instructions. He said that model won't work well in an AI-heavy environment, where people have to take more initiative. For businesses, the implication is practical: employees need to be close enough to the work to spot problems and empowered enough to act on them.
Keep hiring junior employees
Dines also urged companies to keep hiring juniors and give them close access to senior colleagues from the start. Early-career staff learn more than how to execute tasks. They learn how decisions are made, how exceptions are handled, and why the company accepts some trade-offs over others.
If AI removes all entry-level tasks without replacing that learning, organisations risk weakening their future talent pipeline. Seniors may get short-term capacity, but the people who would have grown into experienced operators, managers, and specialists can be lost. The point isn't to preserve repetitive work for its own sake - it's to design junior roles around supervised judgment, process understanding, and review of AI-supported work.
For example, a junior employee might check AI-prepared customer responses against policy, investigate exceptions, and talk through edge cases with a senior colleague. That work can teach the reasoning behind decisions, not just the mechanics of typing a reply. The model should support the work without becoming the only place where operational knowledge lives.
Build learning into the operating process
A rollout can be built around a short cycle:
- Map the process and identify where people currently use judgment.
- Pick a bounded task where AI can reduce effort without owning the full outcome.
- Pair the system with employees who understand the workflow and can review exceptions.
- Log recurring errors, missing context, and useful fixes.
- Adjust permissions, process, or training before expanding autonomy.
This creates feedback from real operations, and it avoids treating adoption as a one-time launch. AI systems and business processes both change, so teams need a way to revisit the original assumptions.
At FUSION, Karl Crowther - who leads UiPath in the Middle East and Africa - said that companies who kept core processes running through disruption were often the ones who automated first. He described automation as a "shock absorber" and noted interest in advanced agentic automation among banks, government agencies, retailers, and oil and gas companies in the UAE.
That's a useful reminder: automation can support resilience, but it doesn't guarantee it. Resilience comes from knowing which processes matter, keeping alternatives available, and ensuring people can step in when automated work fails. The UAE government's adoption efforts were praised by Dines, but the underlying operating question applies everywhere: can your people actually see, understand, and control the systems they depend on?
Key takeaways
- Delegating work does not delegate accountability. Someone has to own the consequences of AI-driven actions.
- Match autonomy to risk. Recommendations, drafts, and low-impact actions may need different approval than customer commitments or financial transactions.
- Use deterministic software where it fits. AI capability alone isn't enough to justify AI in a stable, testable workflow.
- Give AI-generated work an operational owner. Generated code and content still need review, testing, and maintenance based on their real impact.
- Design roles around judgment and learning. Keep junior employees close to experienced colleagues so process knowledge and decision-making skills keep growing.
- Expand from evidence, not excitement. Start with a bounded task, watch how failures happen, and improve controls before granting broader authority.
Conclusion
AI can take on more work, but the important management question isn't how much autonomy a company can grant. It's how much autonomy it can control, verify, and recover from when conditions change.
Start with the process, not the technology. Choose a task where AI adds real value, assign an accountable owner, set clear boundaries, and test what happens when the system gets it wrong. Use conventional software where repeatability matters more than interpretation - and keep people close to decisions that carry consequences.
The organisations best positioned to benefit from AI won't be the ones that remove people from the loop by default. They'll be the ones that redesign the loop so people can steer the system with context, authority, and a clear view of what happens next.