AI Due Diligence Questions Buyers Ask About Your Company

Buyers and investors ask AI due diligence questions in three areas: what your agents do and who controls them, what data they touch and where it goes, and which contracts and people the setup depends on. Expect to hand over an inventory of agents, permission and approval records, data flow descriptions, provider agreements and evidence that the system works. Companies that produce these quickly and consistently look like they run AI on purpose, not by accident.

Key takeaways

• Buyers test three things: that the AI setup works, that named people control it, and that it can transfer to a new owner without breaking or leaking.
• Build the agent inventory first. Every other answer hangs from it: role, owner, tools, data, permissions and provider.
• Data questions center on what each agent can read, what it remembers, which providers receive it and whether anyone trains on it.
• Contracts matter as much as architecture: ownership of configuration, assignment rights, exit help and data return.
• Evidence beats description. Evaluation results, change records and incident logs persuade more than a slide.

What are buyers really testing when they ask about AI?

A buyer is looking for liabilities, dependencies and overstated value. In ordinary software review that means security, privacy and ownership of code. AI agents add a twist because they act: they read mail, update records, call tools with credentials and remember things. An agent with broad access is an asset when it is controlled and a risk when nobody can say what it may do.

Three questions sit under almost every request. Does it work, and can you show evidence? Is it controlled by named people with clear limits? Can it transfer to a new owner without breaking or leaking? Reviewers often borrow vocabulary from the NIST AI Risk Management Framework and the OWASP Top 10 for LLM Applications. If you operate in or sell into the European Union, they may also ask how your use cases relate to the EU AI Act, whose obligations depend on the use and on your role. You do not need to certify against any of these. You need answers that agree with each other.

The fastest way to get consistent answers is to draw the system once. A one-page architecture map showing models, memory, integrations and hosting becomes the spine for every later response.

Which documents about your agents will a buyer request?

Expect a request list that looks like the one below. Not every item needs to be long. A short, accurate page beats a long, stale one.

• Agent inventory: every agent, its role, business owner, technical operator, channels, and whether it is in pilot or production.
• Role description: what the agent may do, what it must never do, and when it escalates to a person.
• Architecture map: models, orchestration, memory stores, integrations and where each one runs.
• Tool and integration register: each connected system, the type of credential used and the scope granted.
• Permission records: who approved each access, how often access is reviewed and the outcome of the last review.
• Approval boundaries: which actions need a human decision before they happen, and who makes it.
• Evaluation evidence: the success criterion, the test cases, results over time and how regressions are caught.
• Change log: edits to instructions, tools and models, with the approver and the rollback path.
• Incident log: what went wrong, the impact, the fix and the follow-up.
• Backup and recovery notes, with a record of a restore test.
• Usage and cost records per agent, including limits and alerts.
• Policies: acceptable use, data handling and the guidance given to employees.

Permissions draw the most attention. Reviewers look for shared logins, broad administrator access and credentials that belong to someone who has left. A scheduled permission review creates the record and removes the problems before anyone asks.

Change and incident logs come next, because they show whether changes are deliberate. An empty incident log for a busy agent reads as not looking, not as perfection.

Finally, expect a test for single points of failure. If one enthusiastic employee or one outside builder is the only person who understands the setup, the buyer will ask how the agents keep running without them.

What do buyers ask about data, memory and model providers?

Data questions are usually the longest part of the review, because they connect to privacy law, customer contracts and trade secrets. Prepare written answers to these:

• Which categories of data can each agent read: customer, employee, financial or confidential commercial information?
• What does the agent store as memory, where is it kept, and who can view or delete it?
• Which model providers and other subprocessors receive prompts and outputs, and in which regions?
• Does any provider retain your data or train on it? Keep the no-training terms in writing.
• If personal data is involved, what is the legal basis, and how do you meet rules such as GDPR or Brazil's LGPD, including access and deletion requests?
• Can one person's data be removed from memory, logs and evaluation sets?
• How do you defend against prompt injection and unintended disclosure? OWASP guidance on LLM applications is a common reference.
• Is customer data ever used to test, tune or demonstrate the agent?

The memory question surprises many owners. An agent that remembers is storing company information somewhere, and that store is a data system like any other. Be ready to say what is kept, for how long and why.

Answer honestly. Saying that a retention period is not yet defined, and showing who will define it and by when, is more credible than a confident answer that a buyer can disprove by comparing it with your integration register.

Which contract terms will a buyer check?

Technical controls can be sound and a deal can still stall on paper. Collect every agreement that touches the AI setup: model providers, platform vendors, implementation partners, freelancers, and any customer contract that restricts how data is processed. Then check each one against this list:

• Ownership: who owns the prompts, configuration, workflows, memory contents and evaluation sets built for you?
• Assignment and change of control: can the agreement transfer to a buyer, does it need consent, and can the provider terminate on a sale?
• Exit: export formats, transition help, and return or deletion of data at termination. The guide to avoiding vendor lock-in covers what to negotiate.
• Subcontractors: are model providers and hosting parties named, and is there notice when they change?
• Data terms: processing agreement, confidentiality, no-training commitment and breach notification duties.
• Liability and insurance: what the provider is responsible for, and what your own cover says about agent mistakes.
• Service commitments: support hours, response expectations and incident communication.
• Term and renewal: minimum commitments and automatic renewals that a buyer would inherit.

Individuals deserve a separate look. Anyone who built an agent for you, employee or contractor, should have assigned their work product in writing.

Illustrative scenario: a services company enters a sale process. The buyer asks who owns the instructions and workflows behind a support agent that a freelancer built. The company finds an agreement that never assigns work product, and the agent's credentials sit in an account that belongs to the freelancer. Nothing is wrong with how the agent behaves, but the buyer asks for a signed assignment and a credential transfer before closing. The process takes longer than anyone planned, and the delay was avoidable.

How can you prepare before a deal opens?

Run this plan before anyone asks. It suits a company with a handful of agents and can be done by a small group.

• Step one, name an owner: one accountable executive coordinates the response and settles conflicting answers.
• Step two, build the inventory: list every agent, including informal ones that employees set up on their own.
• Step three, draw the map: models, memory, integrations and hosting on a single page.
• Step four, review permissions: remove unused access, replace shared logins and rotate credentials tied to people who left.
• Step five, gather evidence: success criterion, evaluation results, change log and incident log, in the form you already keep them.
• Step six, read the contracts: mark assignment, exit, data and liability terms, then list gaps with a proposed fix for each.
• Step seven, write the data position: categories, flows, providers, retention and deletion.
• Step eight, test recovery: restore an agent's configuration and memory in a safe environment and record the result.
• Step nine, rehearse: ask someone who did not build the setup to answer the request list from the documents alone.

The rehearsal shows whether knowledge lives in documents or in heads. Fix what it exposes, then keep the records current so the exercise is not repeated from scratch.

Be Human's managed approach is designed so these records exist as a by-product of operations. A first engagement defines one role, the memory and tools it needs, approval boundaries and an observable success criterion, which gives you a role description and an evaluation target from the start. Managed operations can include monitoring, recurring evaluations, permission review, integration maintenance and incident response, so permission records, change history and incident notes build up through routine work. The agent's identity, memory, channels and tools stay under human control throughout. None of this guarantees a particular outcome in a deal. It makes your answers verifiable.

Frequently asked questions

Do we need a formal AI policy before a sale process? A formal policy is not required for every company, but buyers will ask what rules employees and agents follow. A short document covering acceptable use, data handling and approval boundaries is enough to start. It matters more that the policy matches what actually happens than that it is long.

Should we tell a buyer about agent mistakes we have already fixed? Yes, in the form your incident log already records them: what happened, the impact, the fix and the follow-up. A documented, handled incident shows control, while a hidden one that surfaces later damages trust. Ask your legal counsel how disclosure should be framed in the transaction documents.

What if we only run one agent? The questions are the same, but the answers are shorter. One agent still has a role, tools, permissions, data access, a provider and contracts, and a buyer will want each one explained. A single well documented agent is a stronger position than several informal ones.

Who should answer buyer questions, legal, IT or the business? Split them by subject and let one coordinator combine the answers. Legal covers contracts and privacy, IT or your operations provider covers architecture and access, and the business owner covers the role and the results. The coordinator makes sure the three versions agree before anything is sent.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.