Agentic Due Diligence: the decision before an AI agent acts
An AI agent becomes a business decision the moment it is allowed to act. Looking up information, changing a record and making a commitment to a customer carry different consequences. Each needs a clear basis for permission.
That is where the conversation becomes serious.
“Boardroom conversations about AI agents open with what’s possible. They turn quickly to what’s safe. The second question decides what ships. Urgency without governance leaves you with an agent nobody can account for, and the board owns that liability.”
Jonny Bowker, Advanced Analytica
The practical question is how to make that conversation useful. What evidence should leaders ask for? Who should review it? What would justify proceeding, and what should stop the work?
At Advanced Analytica, we have developed an Agentic Due Diligence process and supporting playbook for our own work and client engagements. We call it ADD. Its purpose is to establish the foundations for a reasoned decision about agentic delivery.
Understanding why that matters means taking one step back: to how technology due diligence has evolved, and what changes when software can choose how to pursue a task.
From checking the technology to understanding the work
Supplier credentials, security controls, architecture, contracts and support arrangements remain important parts of technology review. Software has executed consequential actions for decades. Agents inherit those responsibilities and introduce further questions about how actions are selected.
One useful way to understand the evolution is through the object being assessed. Start with the product. Extend the review to the quality of its outputs. Then examine the whole arrangement through which an output becomes an action.
A supplier can describe its security measures. A model evaluation can show performance on selected tasks. The business still needs to establish whether its own data, permissions, processes and responsibilities support the proposed use.
Imagine an agent responding to a delivery query. Its answer might depend on customer records, warehouse information and a carrier’s latest update. Its ability to change anything should depend on a separate set of permissions.
The useful unit of assessment is the complete task in its business setting. That includes the people who handle exceptions and the consequences when information is incomplete.
Consider three boundaries: what the system can see, what it can decide and what it can change. Those boundaries may differ within the same task. An agent could retrieve a delivery status and draft a response while requiring approval before changing an address. Treating the whole task as simply approved would hide that distinction.
Due diligence should make those boundaries explicit enough for delivery teams to implement and process owners to understand. The resulting record should explain the intended authority in terms the business can use.
Right-size due diligence to the work
The depth of due diligence should follow the work, its authority and the consequences of failure. Applying the same assessment to every organisation wastes attention that should go towards the decisions carrying the greatest risk.
ISO/IEC 42001 sets requirements for an organisational AI management system. NIST’s voluntary AI Risk Management Framework supports the management of AI risks. They serve different purposes. NIST explicitly allows contextual tailoring and explains that its actions do not constitute a checklist.
Both can inform the work. Our starting point is the client’s decision, with the relevant requirements and guidance applied to it. A full certification programme or assessment against every framework category needs a clear reason and an agreed scope.
Consider an internal assistant drafting answers from approved reference material, with every response checked before use. Compare it with an agent authorised to change customer records or commit money. Their permissions, data exposure, review needs and failure consequences call for different assessments.
Company size alone cannot determine the depth. A small business can run a consequential process. A large organisation can have a tightly bounded use case. Examine autonomy, sensitive information, affected people, dependencies and how readily an action can be reversed.
Reuse sound policies and controls where they apply. Focus additional work on the gaps. Applicable obligations and contractual commitments still need to be met, and significant uncertainty may justify deeper review.
The output should explain what was assessed, why that depth was appropriate and what would trigger reassessment. Right-sizing takes human expertise: someone must judge whether the evidence is sufficient for this decision.
Give Agentic Due Diligence a clear boundary
At Advanced Analytica, ADD covers three foundation phases: governance strategy, business mapping and data controls.
These establish what the organisation permits, how the relevant work happens and which safeguards need to support it. Our wider playbook then continues into the data platform, agentic systems and operation.
That boundary gives each decision a useful scope. ADD establishes whether the foundations support progression. Delivery develops and tests the approved systems. Operation manages their continuing use and provides evidence for subsequent review.
An initial business need gives the process direction. It might be reducing delays in customer enquiries or improving access to operational information. Business mapping can reveal possible opportunities, while detailed opportunity assessment belongs later in delivery.
This sequence helps avoid committing to a particular agent before understanding the conditions it would depend on.
Phase 1: make governance specific
The first phase tests governance against the intended work. An AI policy needs to address the decisions the organisation is preparing to make.
Review whether the relevant documents exist, remain current and cover AI. Check how the AI and data strategies connect to data protection and security policies. Identify contradictions, missing responsibilities and assumptions that need confirmation.
Then name the people responsible for AI risk. Depending on the organisation, that may involve a steering group, functional stewards and departmental champions. Each role needs a practical remit and a clear route for decisions.
For the delivery enquiry example, the policy review should establish who can authorise access to customer information and who decides whether the system may make commitments. Those are business responsibilities with technical consequences.
Where documents need attention, work through the gaps with the people who own them. Templates can accelerate drafting, but the client retains ownership of its final policies and strategies.
The output is a documented view of policy fit, named risk owners, required remediation and a verdict on readiness for the next phase.
Governance becomes useful when someone can use it to resolve an actual decision.
Phase 2: map the business as it operates
The second phase builds a governed register of the business within scope. Record the teams, roles, decision-makers, software, tools and data sets involved, together with their locations and owners.
Then follow the work. Trace how information moves between systems, where people intervene and how exceptions are handled. Record personal data, handovers, delays and repeated effort.
A shared application can support different processes across sites or functions. The register should reflect those differences wherever they affect the assessment.
In our illustrative delivery enquiry, the customer service team might use one record while the warehouse relies on another. Mapping should establish which source supports each decision and who resolves disagreement between them.
The register also needs a distinct review, whether the client builds it from our template or we develop it with their teams. Checking it against the supplier ledger can help identify tools omitted from the initial inventory.
The output is a reviewed account of the work, its assets and responsibilities, with gaps and risk findings recorded against agreed criteria.
That creates a practical basis for designing controls around the business people actually run.
Phase 3: connect controls to consequences
The third phase connects the mapped processes to impact assessments and controls. We structure a master impact assessment with a section for each process, covering data protection and business impact.
The data protection perspective examines the information involved, the recorded basis for its use, risks and safeguards. The business perspective considers the effects of failure on operations, customers and reputation.
For the delivery enquiry, the assessment might examine an incorrect status update, disclosure to the wrong person or an unsupported promise. These examples help the team define what the system should be prevented from doing and when someone must intervene.
Attach relevant data quality and privacy controls to the register. Give each control an owner, a link to the policy requirement it supports and a way to check whether it works.
Agree the review responsibilities. The data protection officer or designated lead reviews that perspective. The process owner reviews business impact. Record the required sign-offs and any conditions.
The output connects policy, process, control, evidence and responsibility. It gives the next phase something concrete to build and test.
Make the judgement visible with rubrics
A review becomes more useful when people can see how its conclusion was reached. Rubrics define the criteria, evidence requirements and basis for a finding. Expert reviewers interpret the evidence and explain their judgement.
We are formalising these elements in our working ADD rubric framework. It is a draft specification to agree for each engagement. We have not presented it as a calibrated numerical scoring model.
Agree the criteria before judging the material. Establish which processes are included, what evidence would satisfy each requirement and which findings would block progression. When comparable items receive different treatment, record the reason. This gives reviewers a shared basis for judgement while allowing the assessment to reflect genuine differences in scope and consequence.
The distinction matters. A percentage can look precise while hiding assumptions about scope, weighting and acceptable risk.
Our working approach records whether a requirement is met, met with bounded actions, not met, not assessed or genuinely outside scope. Each finding needs a reason tied to the evidence examined.
Missing evidence deserves careful treatment. If a review has not happened, the finding remains unassessed. That does not prove the underlying control is absent, and it cannot support a pass.
A known blocking issue also keeps its significance. Strong documentation elsewhere cannot average it away.
This makes the rubric useful to both sides of the discussion: the reviewer explaining a concern and the business owner deciding what must happen next.
Turn findings into a decision
The phase verdict should tell the organisation what it can do next. Our working framework distinguishes four outcomes.
Go: the required criteria are met or have justified exclusions, with no unresolved actions. Conditional go: assessed findings support progression within accepted limits, with named actions, owners and dates. No go: reviewed evidence establishes a condition that blocks the agreed next step. Review required: required evidence remains unassessed or an applicability decision is unresolved.
A known blocker takes precedence even while other evidence is being gathered. The decision applies to the stated scope and next step.
That makes a conditional decision especially important to write clearly. State what may proceed, which limits apply, who owns each action and how completion will be accepted.
Keep the evidence source, version, review date and rationale alongside the finding. Record who accepts the verdict. Someone returning to the assessment should be able to reconstruct the decision without relying on memory.
This is how due diligence becomes a useful management record: a clear account of what was known, what was accepted and what still needed attention.
Design the system around the outcome
The next evolution is in how we design the response. Viewing design as a system helps connect the desired outcome to the dependencies that make it possible.
Return to the delivery enquiry. The desired outcome might be a timely, accurate response based on authorised information. A design tree can branch from that outcome into identity, source selection, permissions, wording, exceptions and escalation.
Each branch ends in a requirement or check. The identity branch establishes whose information may be retrieved. The source branch establishes which record supports the answer. The escalation branch establishes who receives an unresolved case.
Record the connections between branches. A confident response cannot compensate for an unreliable source. An escalation route needs an available person with the authority to act.
Each branch can also suggest a test. If the source has no current delivery update, the expected behaviour might be to explain the limitation and route the enquiry to a person. If the customer asks for a change outside the agreed authority, the system should follow the defined approval route. These scenarios turn broad intentions into behaviour that a team can examine before making the service available.
The tree is a practical planning aid. Use it where it helps the team understand decisions and dependencies, and keep it as simple as the work allows.
This brings creativity into the assessment itself. Teams can explore different ways to achieve the outcome, including a smaller scope or a simpler workflow, using the same visible requirements.
Make human oversight workable
Human oversight needs the same attention as every other part of the design. Naming a reviewer is only the beginning.
The person needs enough information to judge the proposed action, sufficient time to respond and authority to change the outcome. The process also needs an answer for absence, uncertainty and disagreement.
In the delivery example, a request for an exception might require approval from someone who can authorise a customer commitment. Sending it to a general inbox would leave the responsibility unclear.
Define what the reviewer receives: the relevant records, the proposed action, the reason for escalation and the decision required. State what happens while the case is waiting.
These details should carry into delivery tests. An approval step that appears complete on a diagram may still be unusable in practice.
Before progression, agree how to pause the work if an accepted condition stops holding. Name who can suspend access, who investigates and who authorises a restart. For the delivery enquiry, this could apply when the source record becomes unreliable or the designated reviewer is unavailable. The response should be proportionate to the issue and clear to the people operating the process. Recording this early also helps delivery teams design a usable route for stopping, resolving and resuming work.
Good oversight is part of the service the organisation designs. It supports the people making decisions and gives customers a workable route through exceptions. The assessment should establish those responsibilities early enough for delivery teams to build them properly.
Carry the evidence into delivery and operation
After ADD, the wider playbook moves into phase 4: the data platform. This develops and tests the governed data arrangements, access and pipelines needed for delivery. The architecture depends on the engagement.
Phase 5 covers agentic systems. Detailed opportunity assessment examines value, feasibility, risk and build cost using the reviewed foundations. Approved systems then move through design, build and testing, with their specific impact assessment completed before build begins.
At this stage, the business case should account for the work surrounding the agent. Review effort, exception handling, maintenance and support all affect the result. A faster first response may offer limited value if it creates more follow-up work for another team.
Agree measures that reflect the intended outcome and the service as a whole. For a delivery enquiry, these could include resolution time, avoidable transfers and the quality of the customer response. Establish a baseline where possible, state what remains uncertain and compare the proposed approach with simpler alternatives.
Agree the outcome, tests, operating runbook and escalation owner. The first five phases each require a recorded go or no-go decision; a phase can return to remediation when the evidence calls for it.
Phase 6 is operation: monitoring performance, managing access, handling incidents and maintaining policy fit.
Operational changes should prompt review of affected findings. A new source, permission or responsibility can change the basis of an earlier decision. Keep the scope and assessment record current enough to show what still applies.
ADD retains its boundary at the first three phases. Its evidence continues to inform the decisions that follow.
Put human expertise at the centre
Human expertise shapes the assessment from the outset: defining scope, asking questions, interpreting evidence and deciding when specialist advice is needed. It gives proportionate due diligence its substance.
The process owner understands how the work runs, including the exceptions missing from a procedure. A data specialist can examine source quality and dependencies. Security and data protection expertise helps assess access, exposure and safeguards. AI expertise helps challenge assumptions about what the proposed system can reliably do. Bring those perspectives together according to the work.
Return to the delivery enquiry. A register might identify a customer record as the approved source. An experienced colleague may know that warehouse staff update a separate record first, leaving a delay between them. That knowledge changes the questions about freshness, wording and escalation. It needs to become recorded evidence that the team can examine.
AI can help organise documents, compare versions and prepare questions. A competent reviewer needs to check its contributions, investigate contradictions and explain the finding. The responsible decision-maker accepts the remaining risk and any conditions of progression.
Expertise also means recognising limits. Record uncertainty, seek the relevant specialist and pause when the evidence cannot support a decision. Keep the reasons visible so another reviewer can understand and challenge them.
That is the evolution we are building towards: expert judgement, supported by evidence, connecting an organisation’s ambition to its authority to act.
Start with the decision you need to make
Boards ask what AI agents can do. Then they ask what’s safe. Governance is the answer to the second question. For a leadership team, the starting point is a business need and the people responsible for it. Bring the relevant policies, an account of the work and the questions that remain unresolved.
Our ADD process and playbook provide a proportionate, expert-led structure for examining those foundations. Governance strategy, business mapping and data controls establish the evidence for deciding whether to proceed and on what terms.
The most useful first conversation is specific. Name the process you want to improve, the action an agent might take and the consequence you need to understand. That gives the assessment a clear purpose from the outset.