Industrial AI Governance: TIA-Ready for Factory AI

Singapore is moving industrial AI governance out of policy language and into a factory-use-case workflow. AutomationSG launched its Trusted Industrial AI-Ready (TIA-Ready) Framework on 29 July 2026, and Singapore Polytechnic said its first Industrial AI and Governance Literacy programme would begin in October.

That matters because industrial AI is no longer confined to isolated analytics. It is being used for machine vision, predictive maintenance, engineering assistance, factory analytics, robot programming and, increasingly, systems that can recommend or initiate actions. Once AI begins influencing production, quality, maintenance or control decisions, model accuracy is only one part of the engineering problem.

Scope one AI use case, not the whole company

TIA-Ready is deliberately narrower than an enterprise-wide certification. AutomationSG describes it as a use-case-scoped, evidence-based recognition pathway. The scope can be one defined AI application, at one site, with stated operating boundaries and conditions.

That is a sensible engineering approach. A vision system rejecting cosmetic defects has a different risk profile from an AI assistant suggesting PLC code. A predictive-maintenance model that raises a work request is different again from an agent that can issue a control command.

Before discussing models, I would write down five things: what the AI is allowed to do, what it is not allowed to do, what data it may access, who remains accountable, and what happens when the AI is unavailable or wrong.

Define authority before model accuracy

Many AI projects begin with a dataset and a target accuracy figure. In an industrial system, authority should come first.

For example, an anomaly model may be allowed to flag a motor for inspection but not stop the machine. A vision model may classify a part and request rejection, while the deterministic PLC still executes the actual reject sequence. An engineering copilot may draft code, but a competent engineer must review and approve it before download.

This is the same boundary we described in our article on AI agents and the PLC write path. General-purpose AI can read widely and assist with analysis, but hazardous motion, interlocks and safety functions should remain under deterministic, validated control.

If the AI has write access, the write path should be explicit: authenticated identity, limited command set, valid operating state, rate limits where appropriate, full logging and a safe fallback.

What evidence is worth keeping

TIA-Ready emphasises evidence. That is useful because industrial AI governance should be auditable from engineering records, not just policy statements.

For a real deployment I would expect to retain the use-case definition, data sources, model or software version, validation results, known limitations, access permissions, change records, incident records, human-override procedure and the acceptance criteria used before release.

For machine vision, that may include false reject and false accept rates by defect class, lighting conditions, camera settings and representative sample sets. For predictive maintenance, it may include the asset population, operating range, failure modes, alarm thresholds and evidence that maintenance teams actually act on the output.

For generative AI and agents, prompt history alone is not enough. The important record is what tools were available, what permissions the model had, what action was proposed or executed, and which human or automated control authorised it.

The plant data still has to be correct

Governance does not repair poor production data. If machine state, part identity, downtime reason or quality result is ambiguous, the AI system will inherit that ambiguity.

We recently wrote about the need to fix OEE and downtime semantics before scaling industrial AI. The same principle applies here. A governed AI system can still make a poor recommendation if the source data is wrong.

In practice, data lineage should include the field source. A tag coming from a PLC, historian, MES, camera, operator entry or maintenance system should not be treated as interchangeable. The system should also know whether a value is measured, inferred, manually entered or generated by another model.

Human oversight needs to be operational, not ceremonial

A checkbox saying “human in the loop” is not enough. The operator or engineer needs enough time, information and authority to intervene.

If an AI system makes 500 recommendations per shift and a supervisor is expected to approve them individually, the approval step will quickly become automatic clicking. If the model can execute immediately and the human only sees an audit log later, that is not meaningful pre-action oversight.

For higher-risk functions, the workflow should define exactly when a person must review, approve, override or escalate. Lower-risk functions can remain automated provided the boundary, monitoring and rollback are clear.

Where ISO/IEC 42001 fits

TIA-Ready is benchmarked against ISO/IEC 42001 but is not a replacement for ISO/IEC 42001 certification. ISO/IEC 42001 is an international management-system standard for establishing, implementing, maintaining and continually improving an AI management system across an organisation.

Singapore’s Accreditation Council already operates an accreditation programme for ISO/IEC 42001 certification bodies. TIA-Ready gives manufacturers and integrators a more bounded entry point: start with one industrial use case, build governance and evidence around it, then decide whether broader management-system adoption is justified.

That is a better fit for many SMEs than starting with a large compliance programme before they have deployed a useful AI application.

Why Malaysian manufacturers and integrators should watch this

TIA-Ready is a Singapore industry initiative, not a Malaysian legal requirement. Malaysian companies should not present it as one.

But Singapore often sits inside the same supply chains, engineering projects and customer assurance discussions as Malaysian manufacturers. If customers begin asking who owns an AI decision, how factory data is protected, how changes are controlled and what evidence exists after an incident, Malaysian suppliers and system integrators will face the same questions whether or not they adopt the Singapore framework.

The useful part is not the logo. It is the discipline of defining a bounded use case and producing evidence that the system is controlled.

A practical starting point for one factory AI project

Choose one AI use case with a measurable production or engineering benefit.
Document its operating boundary, excluded uses and required fallback.
Identify every data source and every action the AI can influence.
Assign an accountable owner for operation, model changes and incidents.
Test normal, degraded and failure conditions before deployment.
Record model/software versions, permissions, validation results and changes.
Keep deterministic machine and safety control independent unless the AI function has been engineered and validated specifically for that authority.

Industrial AI will become more capable and more autonomous. The right response is not to keep it away from factories. It is to give each use case a clear boundary, measurable evidence and a control architecture that still behaves safely when the model is wrong.

Sources

Featured image: Nenad Stojković (Shixart1985) / Wikimedia Commons, CC BY 2.0.

Industrial AI and automation engineering

CANS works on industrial automation, embedded systems, machine connectivity, OEE and production data, machine vision, condition monitoring, edge systems and industrial AI integration for manufacturing environments.

Contact CANS or WhatsApp CANS.

Industrial AI Governance in Singapore: What TIA-Ready Means for Factory AI Projects