WestBridge Counsel · June 2026 · Note
"Responsible AI" has become a slogan that companies feel obliged to repeat without anyone agreeing on what it commits them to. As counsel, we are less interested in the principle than in the question a buyer's security team or a regulator will actually ask: what did you do, and can you show it? Responsible AI is not a posture. It is the ability to answer that question without improvising.
Start with the obligations you already have
Most companies deploying AI do not need a new body of law to worry about. The law they are already subject to applies to what the model does. Consumer-protection rules reach misleading claims about what a product can do. Anti-discrimination rules reach decisions that affect people unequally, whether a person or a model made them. Privacy law reaches the personal data going in and coming out. Contract and intellectual-property law reach what you promised customers and what you are allowed to use. "The model decided" is not a defense to any of them.
The practical first step is unglamorous: map the AI features you ship to the obligations that already bind you, before adding anything AI-specific on top.
Know whether you are the builder, the deployer, or both
Responsibility tracks your role. A company training or fine-tuning its own model carries obligations around its training data and the claims it makes about the result. A company that embeds someone else's model carries a different set: it has imported risk it did not create and now has to manage, including whatever the provider disclaimed in its terms. Most of our clients are deployers who assumed they were just users, and the gap between those two roles is where the exposure sits.
Write down how the model is allowed to be used
An acceptable-use position for your own AI features is worth more than any framework. It should say plainly what the system may be used for, what it must not be used for, where a human stays in the loop, and what happens when the output is wrong. This is the document that lets you say no to the customer who wants to point your tool at a use you never underwrote, and it is the first thing a careful counterparty will ask to see.
Be able to answer three questions
When a sophisticated customer or a regulator engages, the questions are usually variations on three: What data does the system learn from and run on? What decisions is it used to make or influence? And what happens, for the person affected and for you, when it gets one wrong? A company that can answer those three clearly is most of the way to "responsible," whatever framework it maps the answers onto afterward.
Govern the inputs and the outputs separately
Inputs are a rights problem: do you have the right to use the data you are feeding the system, for this purpose, including any personal data inside it? Outputs are a liability and ownership problem: who owns what the model produces, what happens if it infringes or defames, and what you have promised the customer about it. These are different risks with different owners, and contracts that blur them tend to fail precisely where it matters.
Document enough to defend the decision
Recognized frameworks such as the NIST AI Risk Management Framework, and emerging regimes such as the EU AI Act, are useful as checklists. But their real value to a company shipping today is the discipline of writing things down: what the system is for, what you tested, what you decided and why. Responsible AI, in the only sense that holds up later, is being able to show your work.
The short version
Responsible AI is not a certificate you earn once. It is a small set of decisions, written down and kept current: your existing obligations mapped to your AI features, your role identified, your permitted uses defined, your inputs and outputs governed, and a record that lets you defend the call you made. That is the version that survives contact with a customer's lawyers and a regulator's first letter.