An AI assistant helps an employee resolve a delayed payment. The demonstration is convincing. Leadership approves it.
A second department then wants something similar.
Should it build another assistant from scratch, or use what already exists?
“Reuse it” sounds obvious. Until someone asks what, exactly, is safe to reuse and who remains responsible.
That is where enterprise AI becomes a leadership decision.
My view is simple: share the capabilities that make AI dependable, while keeping responsibility for each business use clear.
Consider one illustrative example throughout: an employee at an institution investigating a delayed customer payment.
Start with the payment, not the platform
Today, the employee opens the payment record, checks processing rules, reviews earlier activity and decides where to escalate.
An AI assistant could bring that information together and suggest the next action. For example: “The payment is awaiting additional verification. Refer it to the review team.”
But a useful answer depends on more than the model. The assistant must find the correct payment, read the current procedure, respect the employee’s access and support its recommendation with evidence.
If every department builds those capabilities separately, the institution repeatedly funds similar work and must maintain each implementation.
The opportunity is to make those foundations available to the next team. The difficult judgment is deciding where common foundations end and business decisions begin.
What should the next team be able to reuse?
Return to our employee investigating the payment.
The assistant needs an approved way to reach an AI model. It needs to retrieve records and procedures within the employee’s permissions. Its answers need testing, and its activity needs enough visibility to investigate a failure.
These are candidates for shared enterprise services.
A second payment team should be able to use those services without rebuilding model access, permission checks, testing tools and monitoring.
But it still needs its own procedures and tests. A domestic payment investigation and a cross-border investigation may require different evidence and escalation decisions.
The enterprise can share how the assistant operates. The payment business must establish what a correct outcome looks like.
That distinction protects reuse from becoming a demand that every business work identically.
Controls must change what the assistant can do
Suppose our assistant finds a record that would explain the delay, but the employee is not authorized to view it.
The access restriction must prevent that record from reaching the model. An instruction asking the model to respect confidentiality is insufficient.
Now suppose the assistant recommends releasing the payment.
That recommendation does not grant permission to execute it. If execution is introduced, the payment workflow must enforce the required authority and approval.
The same distinction applies to human review. An employee cannot meaningfully challenge a recommendation without seeing its supporting evidence and having time to assess it.
For leadership, the question becomes concrete: what prevents this assistant from crossing its authority?
A shared control service can help enforce the boundary. The payment owner still has to define it.
Monitoring must help someone resolve the failure
One morning, the assistant recommends the wrong escalation team.
The service is available. Its response is fast. The employee still receives bad advice.
This is why AI observability matters: the people operating the service need enough evidence to investigate what happened.
For our payment assistant, they might need to establish which procedure was retrieved, whether it was current and which version of the assistant produced the recommendation.
Then someone must act. If an outdated procedure caused the problem, who corrects it? If a shared service caused it, who contains the impact? Can employees continue investigations while the assistant is unavailable?
Recording everything is not automatically the answer. Payment records and customer information also need protection in monitoring systems.
The practical test is whether the institution can explain the failure, contain it and continue the work with appropriately protected evidence.
Reuse also spreads the consequences of change
The payment assistant works well. Several teams adopt its shared services.
Then an update to the document retrieval service starts returning outdated procedures. Our employee receives the wrong escalation advice again but this time other teams may be affected too.
The efficiency of reuse now creates a common dependency.
Before releasing that change, the service owner should know which teams depend on it, whether their important scenarios still pass and how to reverse the update if necessary.
That adds effort to releases. It can also prevent each consuming team from discovering the same defect independently.
The leadership tradeoff is explicit: faster reuse requires sustained investment in the reliability of what is shared.
Someone must own the service after launch
Who takes the call when our payment employee receives bad advice?
A workable arrangement gives the shared-service owner responsibility for its reliability, supported features and changes. The payment product owner remains responsible for the investigation workflow, procedures and acceptable outcomes.
When the cause is uncertain, they need an agreed incident lead. The employee should not have to resolve an organizational boundary before receiving support.
This is why shared AI capabilities need product ownership. Someone must understand consuming teams’ needs, prioritize improvements, explain limitations and support adoption.
That responsibility continues when a service is replaced. The payment assistant needs a tested migration and a clear transition before its existing dependency is retired.
Judge reuse by the payment investigation
A rising number of assistants using the platform may look encouraging. It does not establish whether payment investigations improved.
Can the employee reach a supported conclusion sooner? Are recommendations correct against representative payment cases? Is less rework required? What does a completed investigation cost once review and support are included?
The shared services must also make the next team’s delivery easier. If integration requires months of exceptions, the platform owner needs to understand why.
There will be compromises. Stronger checks may add response time. More evidence may increase storage costs. Central services may reduce duplication while making teams dependent on a common release schedule.
Those costs belong in the assessment of value.
Our payment example leaves leadership with one useful test:
Can the next team reuse the foundations with less effort, while still knowing who owns the business result?
If responsibility becomes harder to locate with every new assistant, the enterprise is accumulating dependencies faster than it is building capability.
Arun Natarajan
© PRODCOB.com | @brownmansocial
Related reading on PRODCOB
- AI at Scale in Banking: The Decision Supply Chain
- Modern Data Architecture: Stop Starting With Technology
- Unity Catalog: Overrated or Misunderstood?
References
- NIST: AI RMF Playbook: Manage
- NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
- NIST: AI Risk Management Framework