The interview subject is the General Counsel of a publicly-traded company in a heavily regulated industry. The company built an AI program in 2024 with the engineering organization in the lead and the compliance organization in the supporting role. By the end of 2025, the compliance organization had effectively become the AI team — making most of the architectural decisions, owning the procurement bar, and driving the engineering team's roadmap. The GC describes the inversion as the most consequential governance change of her tenure. We sat down with her for thirty-eight minutes. She asked us not to name the company or the industry, though she was clear that the lessons generalize.
On how the inversion happened.
Knyte: Walk me through the shift.
General Counsel: The shift was not announced. It happened. The engineering team built the first AI features in early 2024 with my team in advisory. By the time the features were close to ship, my team's review had surfaced enough material concerns — data classification, audit trail, decision provenance — that the engineering team understood they could not ship without the architectural changes my team was requesting. The architectural changes were not minor. They required reworking the data path, the model architecture, and the workflow runtime. The engineering team did the work. By the time the features actually shipped, my team had been the architect of the program in everything but title.
Knyte: And the engineering team accepted that.
General Counsel: They accepted it because the alternative was not shipping. We are in an industry where shipping a non-compliant feature is not a slap on the wrist; it is a regulatory event. The engineering team understood the stakes and made the right choice, which was to redesign the architecture to compliance specifications rather than to ship something that would have to be pulled back. The redesign delayed the launch by about two quarters. The launch that did happen was clean.
On what compliance owns now.
Knyte: What does compliance own that it did not before.
General Counsel: Everything material to the AI program. The architecture decisions — tenant-owned weights, audit-trail design, editor-in-the-loop defaults. The procurement decisions — which vendors we will and will not consider. The data-classification decisions — what corpus content the AI is allowed to access. The eval design — what we measure to demonstrate compliance with our regulatory requirements. None of these are decisions the engineering team makes alone anymore. The engineering team builds; my team specifies the bar that what is built has to clear.
Knyte: That is a meaningful expansion of compliance's role.
General Counsel: It is, and I want to be careful about how I describe it. We did not seize the role. The role accreted to us because the AI architecture decisions are, structurally, compliance decisions in our industry. Where the data lives, who owns the model weights, what decisions get audited, which actions require human sign-off — these are all questions whose answers determine whether we can defend the program in a regulatory examination. The engineering team has the technical expertise to implement; my team has the regulatory expertise to specify what to implement. The two have to work together. In our case, the regulatory side ended up driving more than is conventional.
On what changed in the company.
Knyte: How did the rest of the company react to compliance becoming the AI team.
General Counsel: The reaction was healthier than I expected. The business teams who use the AI features had been frustrated with the slow pace of the original engineering-led program. When my team took on the architectural specification, the cadence changed. We were able to produce specifications that the engineering team could build to, and the business teams could see the program advancing in a way that the regulatory bar was being met as part of, not in tension with, the build. The features that have shipped under the new model have shipped on time and have not produced compliance events. Both are improvements over the prior model.
General Counsel: The board is also more comfortable with the program now. AI was a board-level concern in 2024 because the compliance posture was not clear. The compliance posture is now clear because my team is specifying it. The board no longer asks whether we are managing AI risk; they ask whether we are realizing AI value. The conversation has moved up.
On the architectural choices that made this possible.
Knyte: Which architecture choices specifically enabled this.
General Counsel: Three. Tenant-owned weights, so the model and the corpus stay inside our regulatory tenancy. Audit-trail observability, so we can defend any decision the system made to a regulator. And editor-in-the-loop as the default, so high-stakes decisions are accountable to a named human at the time the decision is made. With these three choices, the rest of the architecture is implementation. Without them, the rest of the architecture cannot be defended at all.
General Counsel: The choices are not unique to our industry. They happen to be load-bearing in our industry because of regulatory specifics, but the underlying logic — that the institution should own the asset, that decisions should be auditable, that high-stakes outputs should have a human accountable — generalizes. I would expect any GC in any industry that takes AI seriously to end up at the same three architectural commitments, if for slightly different reasons.
On what she tells peer GCs.
Knyte: What is the message.
General Counsel: Three things. First, do not wait to be brought in. The architecture decisions are being made now in your AI program; if compliance is not at the table, the decisions will be made on engineering trade-offs alone, and you will be brought in to defend choices you did not participate in. Second, learn the architecture vocabulary. The decisions that matter most — weight ownership, audit trail, editor accountability — are decisions you can make a defensible call on once you understand the vocabulary, but they are unintelligible without it. Third, do not be afraid to specify. The engineering team will build to specifications. They cannot build to specifications you have not produced. The expansion of compliance's role is upstream of the technical work, not downstream of it.
General Counsel: The most important thing I want peer GCs to hear is that this role is available to them. It is not about elbowing into engineering's territory. It is about doing the work the engineering team needs done in order to ship something the institution can defend. The work is gratifying. The relationships with engineering improve when compliance is producing specifications rather than asking pointed questions after the fact. And the regulatory posture is materially stronger when the architecture was built to it from the start.