If your business operates in one of the sectors covered by the Security of Critical Infrastructure Act 2018, energy, water, health, food and grocery, communications or transport among them, an open-weight AI deployment carries obligations a generic vendor pitch will not mention.
The Act requires responsible entities to manage cyber and information security risks to critical infrastructure assets. A self-hosted model running on your own infrastructure sits squarely inside that scope in a way a managed cloud service usually does not, because the infrastructure is yours and so is the risk.
This is not a reason to avoid open-weight models. It is a reason to treat the deployment as a critical infrastructure change rather than a software trial, and to book the right people into the conversation at the start.
What changes in practice
An open-weight deployment in a covered sector has to answer questions a standard IT project would not:
Does the model, or anything it connects to, touch operational technology systems? If so, what is the incident reporting obligation when something goes wrong, and who makes that call at 3am?
Who has access to the model weights and the infrastructure running them, and does that access list match your existing critical infrastructure risk management program?
What happens to your reporting obligations if the model was trained overseas and the licence terms are unclear about data handling?
If the model is doing something today that a person did before, what is the manual fallback when it is unavailable, and has anyone tested it recently?
The gap that keeps appearing
Most SOCI-covered businesses already have a risk management program for physical and IT assets, and it is usually competent. The gap we see is organisational rather than technical. The AI deployment gets scoped by the technology team as a productivity project, and the compliance team never sees it until an audit asks what AI systems are touching critical assets.
Nobody is at fault in that sequence. A tool that summarises maintenance logs does not feel like a critical infrastructure change, right up until someone traces what it can read. The classification depends on connectivity rather than purpose, and connectivity is exactly what nobody documents during a pilot.
A practical starting point
Before any open-weight model goes near a covered asset, even for something as ordinary as summarising maintenance logs or triaging support tickets, three things are worth doing:
Loop in whoever owns your critical infrastructure risk management program before the pilot starts, not after. This is a conversation, not a submission, and it is usually short.
Document which specific systems the model can read from or write to, and keep that list current as the deployment grows. Scope creep is the failure mode here, and it is quiet.
Confirm whether your sector-specific regulator, on top of the Act itself, has its own AI or technology risk guidance. Several do, and it is rarely in the same place.
What skipping it costs
One operator we spoke with had to unwind a support-ticket AI pilot after discovering it had indirect read access to an operational technology network. Indirect is the important word: nobody had connected the model to OT deliberately. It read from a ticketing system that pulled from a monitoring feed that sat on the wrong side of a boundary.
The fix cost close to $60,000 once the security review and remediation were finished, for a problem a half-day scoping conversation would have caught before anything was built. That is the whole argument for front-loading the compliance conversation, and it holds regardless of which model you pick.
Where an open-weight model still makes sense here
None of the above rules out self-hosting, and in some covered sectors it is the better answer. An operator with an existing OT security function, an air-gapped environment and staff who already maintain industrial control systems is better placed to run a local model safely than most businesses in any sector. The capability exists; it just has to be acknowledged in the plan rather than assumed.
Start with a workflow that has no path to operational technology at all, however indirect. Corporate document processing is a reasonable first candidate.
Treat the model deployment as an asset in your existing register from day one, with an owner, a review date and a documented dependency list.
Rehearse the failure. If the model is down for a week, what happens, and does anyone still remember how to do it manually?
Claude's managed infrastructure and audit trail make this scoping conversation considerably shorter than starting from a self-hosted deployment, because several of the questions above have documented answers rather than answers you have to construct. The questions still apply either way, and a managed platform does not exempt anyone from asking them. It just means fewer of them land back on your own team to evidence.
If you have an AI pilot planned anywhere near a covered asset, the cheapest version of this is a scoping conversation before the build rather than a security review after it. book a session and we will map what it touches before anything gets connected.
