Superintelligence Legal Risks for Companies: A GC Map

The legal risks of superintelligence for companies are mostly familiar questions that get harder as agents gain autonomy: who is liable, what the contracts allocate, what personal data the agent remembers and what records exist afterward. General counsel can prepare now by mapping where an agent can act, who answers for the result and what evidence is kept. That map is useful for today's agents and still holds as models become more capable.

Key takeaways

• An agent has no legal standing of its own, so responsibility for its actions falls on the company that deployed it and, depending on the contract, on its vendors.
• Most exposure sits in the gaps between contracts: vendor terms, customer terms and the internal scope of the agent often disagree.
• Memory changes the privacy analysis, because an agent that remembers keeps personal data for as long as the memory exists.
• Logs are both your best defense and a discoverable record, so retention, privilege and access rules need deciding before an incident.
• A written map of agent roles, permissions, approvers and evidence is the single most useful preparation, and it can be built without any new technology.

What does superintelligence change for a legal team?

No one needs to settle the definition of superintelligence to do useful legal work. What matters is capability: an agent that can read many sources, remember context, use tools, take actions in company systems and handle tasks that once needed a skilled employee. Each added capability moves a risk from theoretical to operational.

A chat assistant that drafts text creates mostly content risk. An agent that sends email, updates records, approves requests or talks to customers creates action risk. Action risk is what legal teams already know how to analyze: authority, supervision, foreseeability, documentation. The difference is speed and scale. A human employee who misreads a policy makes one error. An agent that misreads it can repeat the error across every case it touches before anyone notices.

So the legal question shifts from "is the output accurate?" to "what was this system allowed to do, who allowed it and how would we know?" The rest of this article takes that question through liability, contracts, privacy and records.

Who is liable when a capable agent makes a mistake?

In most legal systems an AI agent is treated as a tool or system operated by someone, not as a party. Customers, employees, regulators and courts will generally look to the company that put it to work. Whether the company can then pass the loss to a vendor depends on the contract and the facts, and the answer varies by jurisdiction, so treat this section as a map of questions rather than conclusions.

Four liability patterns deserve a line in your risk register:

• Unauthorized commitments: the agent promises a refund, a delivery date or a contract term that no one with authority approved. The question is whether the counterparty could reasonably believe the agent spoke for the company.
• Unsupervised decisions about people: the agent screens candidates, ranks customers or flags employees. Discrimination, transparency and human review obligations may apply.
• Disclosure: the agent reveals confidential or personal information to the wrong person, inside or outside the company.
• Harmful content: the agent produces a statement about a person or competitor that is false, or advice that a customer relies on.

In each pattern, a standard of reasonable supervision tends to matter. Can the company show that it defined what the agent may do, limited its access, required approval for consequential actions and reviewed its behavior? Those are governance facts, and legal can ask for them in advance. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) offers a neutral vocabulary for documenting them (govern, map, measure, manage) that outside counsel, auditors and insurers can recognize.

Insurance belongs in this conversation early. Many policies were written before agents existed, so coverage for an agent's mistake may be unclear. The questions to put to your broker are collected in Insurance for AI Agent Mistakes: What to Ask Your Broker.

Which contracts need attention first?

Three sets of contracts interact, and the risk sits where they disagree: the agreement with the AI provider or implementation partner, your agreements with customers and partners, and your internal policies and employment terms.

For the provider side, review these terms before the agent gains more access:

• Scope of service: is the agent's role described precisely, or only as "AI services"?
• Data use: can your data, prompts or the agent's accumulated memory be used to train models or improve other customers' services?
• Subprocessors: which model providers and hosting parties touch your data, and how are you told when they change?
• Model and tool changes: will you receive notice when the underlying model, tools or behavior change in ways that affect risk?
• Audit and log access: can you obtain the records you would need in a dispute or regulatory inquiry?
• Incident handling: what is the notification duty, and who acts first?
• Ownership: who owns outputs, prompts, configuration and the memory the agent builds from your operations?
• Exit: can you take your configuration, memory and logs with you in a usable form?
• Liability allocation: do caps and exclusions realistically fit the harm an acting agent can cause?

A written scope document prevents many of these disputes. AI Agent Statement of Work: What to Put in It, Section by Section walks through the sections legal can review line by line.

On the customer side, check whether your agreements restrict automated processing, require disclosure that a customer is dealing with an AI system, or promise confidentiality that an agent's tools could undermine. If an agent will read customer documents, the confidentiality clause and the subprocessor list need to match what actually happens.

What privacy questions does a remembering agent raise?

Memory is what makes an agent useful and what makes privacy analysis different. A system that retains conversations, preferences and case history holds personal data in a store that can be searched, summarized and reused. That raises the ordinary questions, now applied to a new kind of system:

• Purpose: is each category of memory kept for a defined purpose, or does the agent store everything it sees?
• Minimization: can the agent do its job with less personal data in context?
• Retention and deletion: when a person asks for deletion, can the company find and remove what the agent remembers about them?
• Access: can a data subject request be answered from the agent's memory and logs?
• Cross-border transfer: where do the model calls, storage and logs physically sit?
• Automated decisions: does the agent's output materially affect a person, triggering review or explanation duties?

Regimes differ. Companies operating in Brazil should look at guidance from the [ANPD](https://www.gov.br/anpd/pt-br), and those serving people in the European Union should understand how the [EU AI Act](https://artificialintelligenceact.eu/) classifies uses by risk alongside existing data protection law. Your counsel will know which apply, but the agent's role description should carry the answer: a role that screens applicants sits in a different category from one that summarizes internal meeting notes.

Location is a recurring sticking point. Legal teams are often told a service is "in the cloud" without a clear answer about which region holds prompts, memory and logs. AI Data Residency for Business: Where Your Company Data Lives explains what to ask.

Records, logs and privilege: what will you be able to show later?

When something goes wrong, the first request is usually for a record: what did the agent see, what did it do and who approved it? A well-run agent produces that record. Legal's job is to decide what is kept, for how long and who may read it.

Useful records for each consequential action include:

• The request or trigger that started the work.
• The sources and memory the agent drew on.
• The tools it called and the actions it took.
• The approval, if one was required, and the identity of the approver.
• The final output and where it went.

There are tensions to resolve. Logs contain personal and confidential data, so keeping them creates privacy duties of its own. Logs may also be subject to legal hold or discovery, so a deletion routine that works for privacy can conflict with a preservation duty. Decide in advance who can suspend deletion and how.

Privilege deserves a separate rule. If lawyers use an agent, or if an agent processes privileged material, define which workspace holds it, who can access it and whether any third party can see prompts or outputs. Keeping privileged work out of general-purpose agent memory is a simple default.

Access control is the other half of evidence. A record is only reliable if the agent could not act outside its permissions in the first place. The [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) describes the least-privilege principles that security teams will use, and legal can ask to see them applied. A recurring check is described in Quarterly AI Agent Permission Review: Steps and Evidence.

A step-by-step plan to map the legal risks

This plan can be run by a general counsel with an operations lead and a security contact. It produces a document, not a software project.

• Step one: list every agent or AI tool in use or planned, with the business owner for each. Include tools staff adopted without a formal project.
• Step two: for each, write a one-sentence role and list the systems it can read and the actions it can take.
• Step three: mark each action as reversible, costly to reverse or irreversible, and require human approval for the last two.
• Step four: list the data categories each agent touches, including personal, confidential, privileged and regulated data.
• Step five: match each agent to its contracts and note gaps in data use, subprocessors, notice of change, log access and exit.
• Step six: define the evidence kept for each consequential action, plus retention, legal hold and deletion rules.
• Step seven: name an incident owner and write the first-hour response: pause the agent, preserve records, notify the right people.
• Step eight: schedule a recurring review, and tie any change to the agent's role or access to a documented approval.

An illustrative scenario shows how the map pays off. A company's support agent can issue goodwill credits. The map shows the action is costly to reverse, so credits above a set threshold require a manager's approval, and the log records the approver. When a customer later disputes a credit, legal can show who approved it, what the agent saw and which policy applied, instead of reconstructing events from memory. This example is illustrative, not a description of any real engagement.

How does a managed approach support the legal team?

Be Human designs, implements and operates AI agents whose identity, memory, channels, tools and permissions stay under the client's control. A first engagement defines one role, the memory and tools it needs, the approval boundaries and an observable success criterion, which gives legal a bounded subject to review instead of an open-ended capability. Managed operations can include monitoring, recurring evaluations, permission review, integration maintenance and incident response, and each of those produces records that legal can use. Changes to an agent go through a defined request and approval path, as described in How to Request and Approve Changes to a Managed AI Agent, so scope does not drift without a decision on file.

Legal teams can start the mapping exercise without any vendor, and the free Be Human AI diagnostic is a way to find the first task worth handing to an agent.

Frequently asked questions

Does the company or the AI vendor carry the liability for an agent's actions? Usually the company that deploys the agent is the first party customers and regulators look to. Whether it can recover from the vendor depends on the contract, including caps, exclusions and indemnities, and on the facts. Review those terms before the agent gains authority to act.

Do we need to disclose to customers that they are dealing with an AI agent? Some jurisdictions and sectors require disclosure in certain situations, and customer contracts may impose their own duties. Even where it is not required, clear disclosure reduces the risk that a customer later claims they were misled. Ask counsel in each market where the agent operates.

Should agent logs be kept or deleted? Both pressures exist: logs are evidence and may be needed for legal hold, but they also contain personal and confidential data. Set a retention period tied to purpose, restrict access, and define who can suspend deletion when a dispute arises. Write the rule before an incident, not during one.

What is the smallest useful step a legal team can take this month? Build the inventory: every agent, its role, its access, its actions and its owner. That single document exposes unmanaged tools, contract gaps and missing approvals, and it gives every later decision a factual base.

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