{"id":155237,"date":"2026-06-22T14:49:45","date_gmt":"2026-06-22T22:49:45","guid":{"rendered":"https:\/\/xira.com\/p\/2026\/06\/22\/if-your-ai-agent-sends-an-email-to-a-regulator-tomorrow-who-is-responsible\/"},"modified":"2026-06-22T14:49:45","modified_gmt":"2026-06-22T22:49:45","slug":"if-your-ai-agent-sends-an-email-to-a-regulator-tomorrow-who-is-responsible","status":"publish","type":"post","link":"https:\/\/xira.com\/p\/2026\/06\/22\/if-your-ai-agent-sends-an-email-to-a-regulator-tomorrow-who-is-responsible\/","title":{"rendered":"If Your AI Agent Sends An Email To A Regulator Tomorrow, Who Is Responsible?"},"content":{"rendered":"
\"\"
<\/figcaption><\/figure>\n

I\u2019ve been in enough conversations with in-house teams lately to know this is no longer abstract. AI agents are moving out of demos and into real workflows. They are drafting, deciding, and triggering actions across systems. And at some point, one of those actions will matter. Legally. Financially. Reputationally.<\/p>\n

When that happens, the first instinct is to reach for the contract. Indemnities. Warranties. Disclaimers.<\/p>\n

But here\u2019s the problem.<\/p>\n

Most of those provisions were written for a different world.<\/p>\n

When Software Starts Acting, Contracts Fall Behind<\/strong><\/p>\n

For years, software behaved predictably. It executed predefined workflows. If something went wrong, we asked two familiar questions: was it misused, or did it malfunction?<\/p>\n

That framing shows up everywhere in contracts.<\/p>\n

Then AI agents arrived.<\/p>\n

They don\u2019t simply execute instructions. They interpret goals. They choose paths. They chain actions across systems. They evolve as models update and guardrails shift.<\/p>\n

That\u2019s not a small change. It\u2019s a structural one.<\/p>\n

And yet, I still see language like: \u201cCustomer is solely responsible for all outputs.\u201d<\/p>\n

All outputs.<\/p>\n

That clause assumes something important. It assumes the customer can control and observe what the system is doing.<\/p>\n

In agentic environments, that assumption breaks quickly.<\/p>\n

A Different Way To Think About Responsibility<\/strong><\/p>\n

Over time, working through real agreements and real deployments, I\u2019ve found that most of the confusion clears up when you anchor on one principle:<\/p>\n

Responsibility = Control + Visibility<\/strong><\/p>\n

It\u2019s simple. Almost deceptively simple.<\/p>\n

But it forces a different conversation.<\/p>\n

If a party does not control how a system behaves, it should not carry full responsibility for that behavior. If a party cannot see what the system is doing, it cannot responsibly own the outcome.<\/p>\n

Responsibility has to follow both.<\/p>\n

If either is missing, the allocation starts to drift away from reality.<\/p>\n

Start With Control<\/strong><\/p>\n

In-house counsel often step into negotiations after the business has already decided to deploy an AI system. By that point, the conversation tends to focus on legal language rather than system structure.<\/p>\n

That\u2019s backward.<\/p>\n

The first question is not \u201cwhat does the clause say?\u201d It\u2019s \u201cwho controls what?\u201d<\/p>\n

Control in agentic systems is layered.<\/p>\n

The provider typically controls the model architecture, training data, guardrails, and update cycles. These define how the system interprets goals and what actions it is capable of taking.<\/p>\n

The customer controls the deployment context. Which systems does the agent connect to? What instructions does it receive? How it fits into business workflows?<\/p>\n

These are not interchangeable.<\/p>\n

When an agent produces an unexpected result, the cause often sits across both domains. A prompt interacts with a model. A configuration interacts with a guardrail.<\/p>\n

If your contract assigns responsibility without mapping those control layers, it\u2019s not allocating risk. It\u2019s guessing.<\/p>\n

For in-house teams, this means one practical shift: before reviewing any AI clause, sit down with product, engineering, or whoever owns the deployment and map the control surface. You don\u2019t need perfection. You need clarity on who actually influences system behavior.<\/p>\n

Then Demand Visibility<\/strong><\/p>\n

Control is only half of the equation.<\/p>\n

The other half is visibility.<\/p>\n

This is where many agreements fall short in a quieter way.<\/p>\n

They promise \u201clogs upon request\u201d or \u201ccommercially reasonable monitoring.\u201d It sounds fine until something goes wrong, and you realize you cannot reconstruct what happened.<\/p>\n

Meaningful visibility is more concrete than that.<\/p>\n

At a minimum, you should be able to answer a few basic questions after any agent action. What action was taken? What triggered it? Which system did it touch? When did it happen? Was there any human validation?<\/p>\n

If you cannot answer those questions, you do not have oversight. You have a blind spot.<\/p>\n

And in a world where agents can trigger downstream consequences across systems, that blind spot matters.<\/p>\n

I often tell teams: if you are being asked to take responsibility for system behavior, make sure you can actually see that behavior. Otherwise, you are accepting exposure without the ability to manage it.<\/p>\n

Where Contracts Go Wrong<\/strong><\/p>\n

Most drafting issues I see come down to a mismatch.<\/p>\n

Responsibility is assigned broadly. Control is fragmented. Visibility is undefined.<\/p>\n

The result is a contract that looks complete on paper but does not hold up when the system acts.<\/p>\n

Take the \u201call outputs\u201d example. In a traditional setting, output might mean a document someone reviews before sending. In an agentic system, output can include actions. Modifying a record. Sending a communication. Triggering a workflow.<\/p>\n

If those actions occur without human review, can the customer realistically own them entirely? Not unless the customer also controls the system\u2019s behavior and can see what it is doing.<\/p>\n

Or take \u201ccommercially reasonable efforts.\u201d Applied uniformly, it treats a low-risk internal summary the same as an action that could create legal obligations. That\u2019s not how risk works in practice.<\/p>\n

The common thread is the same: the contract does not reflect how the system actually operates.<\/p>\n

How In-House Counsel Can Use This Framework<\/strong><\/p>\n

The point of the \u201cControl + Visibility\u201d model is not to add another layer of theory. It\u2019s to give you a practical way to approach AI contracts.<\/p>\n

Before negotiating responsibility, map the system. Who controls the model? Who controls deployment? Where do those boundaries interact?<\/p>\n

Then test visibility. What can you actually see? Are logs defined? Is monitoring real-time or retrospective? Are high-impact actions treated differently?<\/p>\n

Once you have those answers, look at the responsibility clause again. Does it align with what you just mapped? Or is it assigning responsibility in places where control or visibility is missing?<\/p>\n

That gap is where you focus your negotiation.<\/p>\n

Sometimes the answer is to narrow the responsibility. Sometimes it\u2019s to increase visibility. Sometimes it\u2019s to clarify control boundaries. Often, it\u2019s a combination of all three.<\/p>\n

But the sequence matters. You cannot fix the clause until you understand the system.<\/p>\n

From Legal Language To Operational Governance<\/strong><\/p>\n

What\u2019s happening here is a broader shift.<\/p>\n

AI contracting is moving away from abstract risk allocation and toward operational governance. The strongest agreements I see are not the ones with the most disclaimers. They define how the system is allowed to act, how those actions are monitored, and what happens when something crosses a boundary.<\/p>\n

Governance is no longer something you layer on top of the system. It is something you embed into how the system operates.<\/p>\n

That requires legal teams to engage a bit earlier and a bit differently. Not only as drafters of language, but as translators between system design and accountability.<\/p>\n

A Simple Model, Used Consistently<\/strong><\/p>\n

If there\u2019s one takeaway, it\u2019s this.<\/p>\n

When systems act, responsibility must follow control. And control must be visible.<\/p>\n

That principle is simple enough to explain in a sentence. But it is strong enough to reshape how you approach AI agreements.<\/p>\n

If you want a visual version of the model and how it applies in practice, I\u2019ve put together a short deck<\/a>.<\/p>\n

Use it as a starting point. Not a conclusion.<\/p>\n

Because the real work isn\u2019t memorizing the framework. It\u2019s applying it to the systems your business is actually deploying.<\/p>\n

And that\u2019s where in-house counsel have the most leverage right now.<\/p>\n

\n

Olga V. Mack is the CEO of TermScout, where she builds legal systems that make contracts faster to understand, easier to operate, and more trustworthy in real business conditions. Her work focuses on how legal rules allocate power, manage risk, and shape decisions under uncertainty.<\/em><\/strong> A serial CEO and former General Counsel, Olga previously led a legal technology company through acquisition by LexisNexis. She teaches at Berkeley Law and is a Fellow at CodeX, the Stanford Center for Legal Informatics.<\/em><\/strong> She has authored several books on legal innovation and technology, delivered six TEDx talks, and her insights regularly appear in Forbes, Bloomberg Law, VentureBeat, TechCrunch, and Above the Law. Her work treats law as essential infrastructure, designed for how organizations actually operate.<\/em><\/strong><\/p>\n

The post If Your AI Agent Sends An Email To A Regulator Tomorrow, Who Is Responsible?<\/a> appeared first on Above the Law<\/a>.<\/p>\n

\"\"
<\/figcaption><\/figure>\n

I\u2019ve been in enough conversations with in-house teams lately to know this is no longer abstract. AI agents are moving out of demos and into real workflows. They are drafting, deciding, and triggering actions across systems. And at some point, one of those actions will matter. Legally. Financially. Reputationally.<\/p>\n

When that happens, the first instinct is to reach for the contract. Indemnities. Warranties. Disclaimers.<\/p>\n

But here\u2019s the problem.<\/p>\n

Most of those provisions were written for a different world.<\/p>\n

When Software Starts Acting, Contracts Fall Behind<\/strong><\/p>\n

For years, software behaved predictably. It executed predefined workflows. If something went wrong, we asked two familiar questions: was it misused, or did it malfunction?<\/p>\n

That framing shows up everywhere in contracts.<\/p>\n

Then AI agents arrived.<\/p>\n

They don\u2019t simply execute instructions. They interpret goals. They choose paths. They chain actions across systems. They evolve as models update and guardrails shift.<\/p>\n

That\u2019s not a small change. It\u2019s a structural one.<\/p>\n

And yet, I still see language like: \u201cCustomer is solely responsible for all outputs.\u201d<\/p>\n

All outputs.<\/p>\n

That clause assumes something important. It assumes the customer can control and observe what the system is doing.<\/p>\n

In agentic environments, that assumption breaks quickly.<\/p>\n

A Different Way To Think About Responsibility<\/strong><\/p>\n

Over time, working through real agreements and real deployments, I\u2019ve found that most of the confusion clears up when you anchor on one principle:<\/p>\n

Responsibility = Control + Visibility<\/strong><\/p>\n

It\u2019s simple. Almost deceptively simple.<\/p>\n

But it forces a different conversation.<\/p>\n

If a party does not control how a system behaves, it should not carry full responsibility for that behavior. If a party cannot see what the system is doing, it cannot responsibly own the outcome.<\/p>\n

Responsibility has to follow both.<\/p>\n

If either is missing, the allocation starts to drift away from reality.<\/p>\n

Start With Control<\/strong><\/p>\n

In-house counsel often step into negotiations after the business has already decided to deploy an AI system. By that point, the conversation tends to focus on legal language rather than system structure.<\/p>\n

That\u2019s backward.<\/p>\n

The first question is not \u201cwhat does the clause say?\u201d It\u2019s \u201cwho controls what?\u201d<\/p>\n

Control in agentic systems is layered.<\/p>\n

The provider typically controls the model architecture, training data, guardrails, and update cycles. These define how the system interprets goals and what actions it is capable of taking.<\/p>\n

The customer controls the deployment context. Which systems does the agent connect to? What instructions does it receive? How it fits into business workflows?<\/p>\n

These are not interchangeable.<\/p>\n

When an agent produces an unexpected result, the cause often sits across both domains. A prompt interacts with a model. A configuration interacts with a guardrail.<\/p>\n

If your contract assigns responsibility without mapping those control layers, it\u2019s not allocating risk. It\u2019s guessing.<\/p>\n

For in-house teams, this means one practical shift: before reviewing any AI clause, sit down with product, engineering, or whoever owns the deployment and map the control surface. You don\u2019t need perfection. You need clarity on who actually influences system behavior.<\/p>\n

Then Demand Visibility<\/strong><\/p>\n

Control is only half of the equation.<\/p>\n

The other half is visibility.<\/p>\n

This is where many agreements fall short in a quieter way.<\/p>\n

They promise \u201clogs upon request\u201d or \u201ccommercially reasonable monitoring.\u201d It sounds fine until something goes wrong, and you realize you cannot reconstruct what happened.<\/p>\n

Meaningful visibility is more concrete than that.<\/p>\n

At a minimum, you should be able to answer a few basic questions after any agent action. What action was taken? What triggered it? Which system did it touch? When did it happen? Was there any human validation?<\/p>\n

If you cannot answer those questions, you do not have oversight. You have a blind spot.<\/p>\n

And in a world where agents can trigger downstream consequences across systems, that blind spot matters.<\/p>\n

I often tell teams: if you are being asked to take responsibility for system behavior, make sure you can actually see that behavior. Otherwise, you are accepting exposure without the ability to manage it.<\/p>\n

Where Contracts Go Wrong<\/strong><\/p>\n

Most drafting issues I see come down to a mismatch.<\/p>\n

Responsibility is assigned broadly. Control is fragmented. Visibility is undefined.<\/p>\n

The result is a contract that looks complete on paper but does not hold up when the system acts.<\/p>\n

Take the \u201call outputs\u201d example. In a traditional setting, output might mean a document someone reviews before sending. In an agentic system, output can include actions. Modifying a record. Sending a communication. Triggering a workflow.<\/p>\n

If those actions occur without human review, can the customer realistically own them entirely? Not unless the customer also controls the system\u2019s behavior and can see what it is doing.<\/p>\n

Or take \u201ccommercially reasonable efforts.\u201d Applied uniformly, it treats a low-risk internal summary the same as an action that could create legal obligations. That\u2019s not how risk works in practice.<\/p>\n

The common thread is the same: the contract does not reflect how the system actually operates.<\/p>\n

How In-House Counsel Can Use This Framework<\/strong><\/p>\n

The point of the \u201cControl + Visibility\u201d model is not to add another layer of theory. It\u2019s to give you a practical way to approach AI contracts.<\/p>\n

Before negotiating responsibility, map the system. Who controls the model? Who controls deployment? Where do those boundaries interact?<\/p>\n

Then test visibility. What can you actually see? Are logs defined? Is monitoring real-time or retrospective? Are high-impact actions treated differently?<\/p>\n

Once you have those answers, look at the responsibility clause again. Does it align with what you just mapped? Or is it assigning responsibility in places where control or visibility is missing?<\/p>\n

That gap is where you focus your negotiation.<\/p>\n

Sometimes the answer is to narrow the responsibility. Sometimes it\u2019s to increase visibility. Sometimes it\u2019s to clarify control boundaries. Often, it\u2019s a combination of all three.<\/p>\n

But the sequence matters. You cannot fix the clause until you understand the system.<\/p>\n

From Legal Language To Operational Governance<\/strong><\/p>\n

What\u2019s happening here is a broader shift.<\/p>\n

AI contracting is moving away from abstract risk allocation and toward operational governance. The strongest agreements I see are not the ones with the most disclaimers. They define how the system is allowed to act, how those actions are monitored, and what happens when something crosses a boundary.<\/p>\n

Governance is no longer something you layer on top of the system. It is something you embed into how the system operates.<\/p>\n

That requires legal teams to engage a bit earlier and a bit differently. Not only as drafters of language, but as translators between system design and accountability.<\/p>\n

A Simple Model, Used Consistently<\/strong><\/p>\n

If there\u2019s one takeaway, it\u2019s this.<\/p>\n

When systems act, responsibility must follow control. And control must be visible.<\/p>\n

That principle is simple enough to explain in a sentence. But it is strong enough to reshape how you approach AI agreements.<\/p>\n

If you want a visual version of the model and how it applies in practice, I\u2019ve put together a short deck<\/a>.<\/p>\n

Use it as a starting point. Not a conclusion.<\/p>\n

Because the real work isn\u2019t memorizing the framework. It\u2019s applying it to the systems your business is actually deploying.<\/p>\n

And that\u2019s where in-house counsel have the most leverage right now.<\/p>\n

\n

Olga V. Mack is the CEO of TermScout, where she builds legal systems that make contracts faster to understand, easier to operate, and more trustworthy in real business conditions. Her work focuses on how legal rules allocate power, manage risk, and shape decisions under uncertainty.<\/em><\/strong> A serial CEO and former General Counsel, Olga previously led a legal technology company through acquisition by LexisNexis. She teaches at Berkeley Law and is a Fellow at CodeX, the Stanford Center for Legal Informatics.<\/em><\/strong> She has authored several books on legal innovation and technology, delivered six TEDx talks, and her insights regularly appear in Forbes, Bloomberg Law, VentureBeat, TechCrunch, and Above the Law. Her work treats law as essential infrastructure, designed for how organizations actually operate.<\/em><\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

I\u2019ve been in enough conversations with in-house teams lately to know this is no longer abstract. AI agents are moving out of demos and into real workflows. They are drafting, deciding, and triggering actions across systems. And at some point, one of those actions will matter. Legally. Financially. Reputationally. When that happens, the first instinct […]<\/p>\n","protected":false},"author":3,"featured_media":155238,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[16],"tags":[],"class_list":["post-155237","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-above_the_law"],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/xira.com\/p\/wp-content\/uploads\/2026\/06\/GettyImages-1979476603-L2UrC7.webp?fit=788%2C443&ssl=1","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/xira.com\/p\/wp-json\/wp\/v2\/posts\/155237","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/xira.com\/p\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/xira.com\/p\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/xira.com\/p\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/xira.com\/p\/wp-json\/wp\/v2\/comments?post=155237"}],"version-history":[{"count":0,"href":"https:\/\/xira.com\/p\/wp-json\/wp\/v2\/posts\/155237\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/xira.com\/p\/wp-json\/wp\/v2\/media\/155238"}],"wp:attachment":[{"href":"https:\/\/xira.com\/p\/wp-json\/wp\/v2\/media?parent=155237"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/xira.com\/p\/wp-json\/wp\/v2\/categories?post=155237"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/xira.com\/p\/wp-json\/wp\/v2\/tags?post=155237"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}