USA – TEXAS Trends and Developments Contributed by: Christina Morgan, Jason Blackstone and Matthew Yarbrough, Buchalter LLP
quickly and prove they did so responsibly. The strat - egy is to design flexibility into both policy and tech - nology. This approach highlights the need for an AI govern - ance programme that includes safety testing, docu - mentation, and harm mitigation, and points to stand - ards frameworks such as NIST and ISO as part of compliance thinking. That is consistent with what regulators are asking for: not perfection, but a pro - gramme. Flexibility is also about cost and speed. A programme that requires outside contractors to make routine changes is not agile; it is a bottleneck. The opera - tional goal should be to empower internal owners to adjust retention schedules, change model routing rules, update prompts and guardrails, and change vendor integrations without a rebuild. This is govern - ance through configuration, not governance through heroic engineering projects. Portability and Vendor Independence Vendor lock-in is not only a procurement problem; it becomes a privacy and cybersecurity problem the moment your vendor’s model behaviour changes, your risk tolerance changes, or a regulator asks you to switch approaches quickly. If you cannot move your data, your features, and your model outputs to anoth - er system, you have lost operational control. A defensible programme therefore includes data and algorithmic portability. At a minimum, you should be able to export your feature definitions, model docu - mentation, and decision logs in usable form. You should know which parts of your pipeline are propri - etary and which parts are replaceable. You should also be able to demonstrate that you evaluated vendor risk and monitored vendor changes as part of your gov - ernance function. Visibility is equally important. In an agent ecosystem, your systems interact with vendor agents and custom - er agents in ways that can create emergent behaviour. If you cannot see those interactions and reconstruct them later, you cannot explain them. Under regimes emphasising transparency and accountability, that
lack of visibility becomes a compliance failure, not merely a technical inconvenience. What is Your Story: Can You Explain Your AI Programme to a Regulator, Legislator, or Judge? The most persuasive compliance posture is a coher - ent story backed by evidence. Your story should be consistent across privacy, cybersecurity, and AI gov - ernance. It should also be consistent across technical and legal audiences. The NIST AI RMF is useful here because it gives you a vocabulary for governance, risk mapping, measurement, and management that can be translated into board-level reporting and into regulator-facing documentation. A credible story typically includes the following ele - ments: • You defined the purpose of the AI system and lim - ited data processing to that purpose. • You used data minimisation and retention disci - pline, including secure disposal. • You documented model inputs, intended use, limi - tations, and monitoring. • You implemented human oversight where it mat - tered. • You evaluated foreseeable risks, including discrimi - nation risk and security risk, and mitigated them. • You retained evidence of decisions and changes so you could reconstruct what happened. These elements track directly to themes in Colorado’s statute around reasonable care, documentation, and impact assessments, and to the EU AI Act’s empha - sis on documentation and transparency. They also track to the FTC’s framing of security as collecting only what you need, protecting it, and disposing of it. The point is not to memorise a framework. The point is to build an operational system of proof. When the question comes, you answer with documents, logs, testing artifacts, and governance records, not with aspiration. Practical Guardrails for the “Data-Light AI” Future Below are guardrails that high-level counsel can insist on without pretending to be engineers. They are prin -
618 CHAMBERS.COM
Powered by FlippingBook