AI Is Moving Into the Core Systems of Regulated Work

Your systems integrator just became an AI vendor.

Within twenty four hours this week, two of the largest IT services firms in the world told their regulated clients the same thing: the AI is going into the core systems, not the chat window. On 11 June, DXC announced a multi-year global alliance with Anthropic to bring Claude into the systems it runs for the world's largest banks, airlines, insurers and government agencies. A day later, Tata Consultancy Services followed with a global premier partnership to deploy Claude across financial services, insurance, healthcare and the public sector, and to put it in front of 50,000 of its own staff across 56 countries.

What actually happened

These are not chatbot pilots. DXC said it will train tens of thousands of Claude-certified engineers to embed the model in platforms that handle transactions, claims and operations under strict security and compliance rules, and that it wrote more than 95 per cent of the code for its new managed-services orchestration platform with Claude. TCS named the specific products it will build: claims processing for insurers, lending advisory for banks. Anthropic's own framing was blunt. Regulated industries need their work to be highly accurate and auditable, it said, and that is precisely why enterprises in those fields are already using the model. Infosys signed a comparable deal back in February, so this is a pattern forming, not a one-off announcement.

What it actually means

The significance is not which model won the contract. It is where the model is going. For two years, enterprise AI in regulated industries mostly lived at the edge. It was a copilot in the browser, a chat assistant a staff member could choose to open or ignore, a productivity feature bolted on beside the real systems. What the systems integrators sell is a different layer entirely. They build and run the core systems that banks and insurers depend on, the ones that move money, adjudicate claims and keep aircraft scheduled. Wiring a frontier model into that layer moves AI from a tool an individual uses to a dependency the whole organisation runs on.

If you have read our piece on the AI pilot-to-scale gap, this is that gap closing, but not the way most playbooks assumed it would. Pilots are not graduating because they suddenly got cleverer or cleared a governance committee. They are being leapfrogged by integrators who already hold the keys to the core systems and the compliance scaffolding around them, and who can offer the model as part of a managed service the client already buys.

Who should care, and why

For Australian practitioners, the detail that matters is the client list. Banks and insurers are the headline customers in both announcements, and both sit inside the APRA-regulated perimeter. The moment an integrator embeds a model into your claims or lending platform, you are no longer running an innovation experiment off to one side. You are taking on a material service arrangement. APRA's CPS 230 Operational Risk Management, in force since 1 July 2025, pulls that arrangement into scope where it supports a critical operation, with obligations to assess it, monitor it and be able to exit it. CPS 234 Information Security reaches the model as an access path into your data. The practical translation is simple. The model your integrator installs belongs in your third-party risk register, your access reviews and your incident response plan, governed as the privileged dependency it is, not parked with the vendor and forgotten.

The insurance line is worth dwelling on, because it is closest to home. Claims processing is exactly the kind of high-volume, evidence-weighing, decision-bearing work where an accuracy or fairness error is not a cosmetic bug. If a model is helping to triage, assess or draft a determination, the human-decision boundary has to be drawn explicitly, and the reasoning has to survive being looked at after the fact, because at some point someone will ask to see it. That holds whether the determination concerns a general insurance claim or a workers compensation one.

Triaging the arrangement: a prompt you can run today

The hard part is not deciding that an embedded model needs governing. It is working out, quickly and consistently, whether a given systems-integrator arrangement actually meets the CPS 230 threshold for a material service provider, or whether it sits below it. CPS 230 defines a material service provider as one your organisation relies on to undertake a critical operation, or that exposes you to material operational risk. That is a judgement call, and judgement calls made informally across a dozen integrator contracts tend to drift.

A model can help you make that triage repeatable. It cannot make the call. What it can do is take the facts of an arrangement, walk them against the published CPS 230 criteria, and hand you a structured first pass that a risk owner then accepts, amends or rejects. The point is consistency before sign-off, not a decision without one.

A standing note before any prompt below. Never paste real personal, claim, health or incident data, or anything commercially sensitive, into a model that is not an approved enterprise instance. Everything below uses placeholder tokens. Keep it that way.

You are assisting an Australian APRA-regulated entity to triage whether a
systems-integrator arrangement is a material service provider arrangement
under APRA Prudential Standard CPS 230 Operational Risk Management.

You are not making the determination. You are producing a structured first
pass for a named risk owner to accept, amend or reject. Do not invent facts.
Where a field is missing, say "not stated" and flag it as a gap to confirm.

Arrangement facts (all values are placeholders, de-identified):
- Integrator / vendor: [VENDOR]
- Service description: [SERVICE_DESCRIPTION]
- Embedded AI model or agent: [MODEL_OR_AGENT]
- Business systems it touches: [SYSTEM_OR_PLATFORM]
- Business processes it supports: [PROCESS]
- Data it can access: [DATA_CATEGORIES]
- Actions it can take (read, draft, recommend, execute): [ACTIONS]
- Existing contract owner / risk owner: [ROLE]

Against CPS 230, assess and lay out:
1. Does the arrangement support a critical operation? State which one and
   why, or why not.
2. Could failure or disruption expose the entity to material operational
   risk? Explain the exposure.
3. On 1 and 2, give a provisional classification: material service provider,
   not material, or unclear / insufficient information.
4. List the specific facts you would need to confirm before the risk owner
   can rely on this classification.
5. If provisionally material, list the CPS 230 obligations that then attach
   (risk assessment, monitoring, ability to exit, incident handling) as a
   checklist, each phrased as an action with an owner.

End with one line: "Human decision required: [ROLE] to confirm
classification and obligations before this is recorded in the register."

Run it with the placeholders filled from a real arrangement, kept de-identified, and you get a consistent skeleton instead of a blank page. To show the shape of the output, here is a short illustrative pass for a de-identified scenario. Treat it as a worked example, not a template answer.

Take an Australian general insurer. A systems integrator, [VENDOR], runs the insurer's claims platform, [SYSTEMORPLATFORM], under a managed-services contract. The integrator has now embedded a model, [MODELORAGENT], that reads incoming claim documents and drafts an initial assessment summary for a claims officer. The data it can access is claim correspondence and supporting documents. Its actions are read and draft only. The contract owner is [ROLE].

A first pass against the prompt returns, in substance: the arrangement supports a critical operation, claims handling, because a sustained failure would directly disrupt the insurer's ability to assess and pay claims; failure or a quality defect in the drafting model could expose the insurer to material operational risk through delay, inconsistent assessments or a downstream fairness issue; provisional classification, material service provider, subject to confirmation; facts to confirm include whether the model only drafts or can also progress a claim, what the integrator's own controls and exit terms are, and where the data physically sits; and if confirmed material, the obligations that attach are a documented risk assessment, ongoing monitoring of accuracy and availability, a tested ability to exit or substitute the service, and inclusion in the incident response plan, each with a named owner.

Then comes the step that matters most. The model has produced a provisional classification and a checklist. It has not classified anything. The named risk owner, the [ROLE] in the prompt, reads the first pass, checks it against the contract and the facts the model flagged as missing, and makes the call. Only after that human decision does the arrangement get recorded as material, or not, in the third-party risk register. The prompt is built to stop at that gate on purpose. A consistent draft that a person signs off is the goal; an unreviewed classification quietly entering the register is the failure mode to avoid.

The hype check

Two cautions are worth naming. First, a global-premier-partner badge is a commercial arrangement, not a safety certificate. "Highly accurate and auditable" is a design goal the integrators are selling toward, not a property you inherit on signing. The auditability has to be demonstrated in your environment, against your data and your decisions, before you rely on it. Second, embedding a model deeper does not make the old risks disappear. A model wired into a core system still reads untrusted inputs and still needs scoped permissions, approval gates on the actions that hurt, and a logged, reversible trail, the same controls any agent deployment needs. Deeper integration raises the blast radius. It does not lower the bar.

What to do this week

You do not need a new AI strategy to respond to this. You need to know what your integrators are already installing.

1. Ask procurement and your technology leads whether any current integrator or managed-services contract now includes an embedded AI model or agent. The answer is increasingly yes, and you want to know before an auditor does.
2. For any that do, run the triage above and confirm whether the arrangement is a material service arrangement. Record the classification and its reasoning in your third-party risk register with a named owner.
3. For any model touching claims, lending or other regulated decisions, write down the human-decision boundary explicitly. State what the model may draft or recommend, and what a person must decide and sign.
4. Confirm you can extract an audit trail of the model's actions and inputs from the integrator's platform, not just a summary dashboard. If you cannot, that is a contract conversation to start now.
5. Reuse, do not reinvent. The controls you already apply to service accounts and critical vendors are most of the controls this needs.

The systems integrators have decided that regulated industries are where frontier AI earns its keep, and they are probably right. The organisations that come out ahead will be the ones that treated the embedded model as core infrastructure, governed under the rules they already have, from the first day. Not the ones that discovered it was core infrastructure during an incident.

References

• Anthropic, DXC and Anthropic alliance to bring Claude into mission-critical enterprise systems, 11 June 2026. https://www.anthropic.com/news/dxc-anthropic-alliance
• Anthropic, TCS and Anthropic partner to bring Claude to regulated industries, 12 June 2026. https://www.anthropic.com/news/tcs-anthropic-partnership
• Anthropic, Infosys and Anthropic to build AI agents for regulated industries, 17 February 2026. https://www.anthropic.com/news/anthropic-infosys
• APRA, Prudential Standard CPS 230 Operational Risk Management. https://www.apra.gov.au/operational-risk-management
• APRA, Prudential Standard CPS 234 Information Security. https://www.apra.gov.au/information-security-requirements-for-all-apra-regulated-entities

General information and education only. Not legal, compliance, or professional advice. Verify any arrangement against your own contracts and the primary APRA sources before acting.*