Public AI vs Internal AI: Two Governance Surfaces

Short answer: An institution answering to a board about customer-facing AI must distinguish between two governance surfaces. The first is public AI: the third-party assistants that answer customer questions about the institution, on infrastructure it does not run. The second is internal AI, the assistant the institution deploys itself or has a vendor run under its authority. From the customer's side they look alike. Both return a confident paragraph about a fee, an eligibility rule, a claims deadline. The governance difference is not that one leaves a record and the other doesn't. It is control and evidence access: how much the institution can configure, suspend, and require evidence from the system producing the answer. That distinction decides which controls are available, what evidence can be obtained, and whom the institution can ask to fix a wrong answer.

Lawnise uses "public AI" and "institution-deployed AI" to distinguish two governance surfaces with different control and evidence-access conditions. It is our framing, not a category borrowed from a standards body, and we set it out here because it organises everything else in this series. We have written elsewhere about AI governance solutions for public-facing answer risk, covering the external surface and why it requires a distinct governance response. This piece is the other half of that map.

What "internal AI" means here, and what it doesn't

The term needs a narrow definition before the comparison is worth anything.

Internal AI, in this piece, means institution-deployed or institution-authorised AI: the customer-facing assistant the institution runs, or the one a vendor runs under its authority and on its behalf. The retail-banking chatbot on the app. The policy-servicing assistant embedded in the claims portal. The support agent a technology partner operates under contract, answering in the institution's name.

It does not mean every AI system that happens to be used inside the building. Staff opening a public assistant at their desks, teams trialling tools outside procurement, individual productivity use: that is a real governance question, and it is a different one, on a different surface, with different controls. We make no claims about it here. Keeping the scope this tight matters, because the two questions get conflated constantly and the controls do not transfer. A data-loss policy for staff tool use tells you nothing about whether the bot on your app quotes the current fee.

So the comparison that follows is between two systems that both answer customers about the institution. One is operated by a third party. The other is run by or for the institution itself.

Public AI vs internal AI: control and evidence access

The tempting version of this comparison is the dramatic one: public AI vanishes without a trace, internal AI leaves a perfect record. It is a clean story and it is wrong. Providers do keep logs. Providers configure and disable their own services. Enterprise assistants are frequently vendor-built rather than built in-house, and how much logging or shutdown control the institution actually holds depends on the architecture and on the contract in place.

The honest distinction is narrower and more useful.

Read down the middle column and the public surface resolves into a specific problem: the institution generally lacks authoritative access to the provider's internal logs, configuration and model-change records. It is not that no records exist. It is that the institution cannot get to them. What remains available is the answer itself, observed, and whatever the assistant cites. That is why the external discipline is built on observation and comparison against the institution's own published record rather than on instrumentation, which is the method we set out in how we verify an AI answer against an official source.

Read down the right-hand column and the internal surface resolves into a different one. The institution can usually reach the system. It can suspend it. It may be able to require the version history and the configuration record. What it holds is a route to evidence, and a clearer ownership and accountability relationship for what the assistant says. The route is real, but it is conditional. An institution that assumes contractual access it never negotiated will discover the gap during an incident rather than before one.

Why enterprise chatbot accuracy is a distinct control

Internal AI governance is not an empty field, and this piece does not claim otherwise. Institutions deploying their own assistants generally have something in place: an inventory of where AI is used, model risk documentation, access controls, bias testing, an acceptable-use policy, an approval path before a system goes live. These are established governance practices in regulated institutions.

But look at what those controls are pointed at. Inventory answers what AI do we run. Model risk answers is this model fit for its purpose. Access answers who may use it. Policy compliance answers is its use within the rules we set. Those controls do not by themselves establish whether a particular answer matched the institution's current approved facts and procedures. That is the question a customer's outcome actually turns on: when this assistant told a customer what a fee was and how long they had to act, was that what our approved record says today?

Traditional internal AI governance often emphasises inventory, model risk, access, bias and policy compliance; answer-level factual and procedural validation is a distinct control. It sits alongside that work rather than in place of it: a specific verification layer within internal AI governance, not a substitute for the governance platform that surrounds it. An institution can hold complete model documentation for a deployed assistant and still not know whether last Tuesday's answers matched the current tariff sheet.

The reason this control has to be deliberate is that it is easily assumed to be someone else's. The institution cannot assume an independent third party is checking whether its chatbot still matches current facts and procedures. Vendor and model testing may evaluate output quality, but institutions should not assume those processes independently verify every answer against their current reference record. That gap between a correct source and a correct answer is the same gap we describe as contextual accuracy on the public surface, and it does not close simply because the institution owns the deployment.

Internal AI validation starts with recorded authorisation

There is a control question that comes before any assessment of a first-party assistant, and it is worth stating plainly because it is where a lot of credibility is won or lost.

Nobody should assess responses from an institution's customer-facing AI without recorded authorisation covering the system and engagement. Lawnise does not begin that assessment without recorded and verified authorisation. The engagement is bound to the specific AI system, authorised, and moving through an approved and active lifecycle before anything runs. That is a deliberate constraint, and in a discipline where the subject of assessment is a system that speaks to real customers, it is the constraint that makes the rest defensible.

Within that boundary, the current capability is specific:

Lawnise can assess first-party enterprise AI answers through an authorised, engagement-enabled manual-intake workflow, using verified reference facts and procedures supplied for that engagement.

Factual and procedural assessment. Compliance rule enablement remains in progress.

Two things follow from stating it that precisely. This is an assessment workflow. It is not ingestion of production logs, and not lifecycle governance of the deployment. And the reference set is the institution's own: the verified reference facts and procedures supplied for that engagement are what the answers are measured against, so the assessment is only as good as the record brought to it. That is the same dependency the external work carries, and the same reason we treat the reference as load-bearing rather than an afterthought.

One analysis layer, two governance surfaces

It would be neat to say the two surfaces need two separate disciplines. They do not require separate answer-verification logic in Lawnise's architecture.

In Lawnise's architecture the answer-analysis layer is the same for both surfaces; what differs is collection, authorisation, confidentiality and evidence access. The question being asked of an answer is always the same one. Does this agree with the current verified reference fact or procedure? That does not change depending on who runs the model. What changes is how the answer reaches us, under what permission, under what confidentiality, and what supporting evidence can be obtained around it.

That is the practical value of holding the distinction clearly. A team that treats the two as one surface will apply internal controls to an external problem and find that many of those controls do not reach the external provider. A team that treats them as unrelated will build the same verification logic twice. The useful posture is to recognise one question about answer correctness, asked under two different sets of access conditions, and to be explicit about which conditions apply where. The external half is the one we measure and publish openly, in our barometers of what public AI says about ASEAN financial services; the internal half runs under engagement confidentiality, which is why it produces no public findings.

Both halves come back to the same governance point, which we have argued at length in why AI answer accuracy is becoming a governance issue: the record can be immaculate and the answer still wrong. Ownership of the system changes what you can do about that. It does not remove the possibility of an incorrect answer.

If you would like to work through which surface your own exposure actually sits on, and what evidence is available on each, we're glad to talk.