General-Purpose AI (GPAI)

Expanded Definition

General-purpose AI, or GPAI, describes a model designed to perform a wide range of tasks rather than a single narrow function. In practice, that means the same base model can be embedded into chat interfaces, workflow automation, search, code assistance, or downstream decision support systems.

The security and governance boundary matters because GPAI introduces layered responsibility. A model provider may carry obligations tied to the base model, while the organisation deploying it may inherit duties for the specific system, data handling, human oversight, and user-facing risk controls. Under the EU AI Act, that split is central to understanding documentation, transparency, and governance expectations.

A common misunderstanding is to treat GPAI as if it were only a product category. For practitioners, the more useful boundary is whether the model is still a reusable base capability or whether it has become a purpose-built system with a distinct operational risk profile.

Examples and Use Cases

GPAI appears wherever a single model is reused across different tasks without being rebuilt for one fixed purpose. The same foundation model may support multiple business processes, each with different controls and risk tolerances.

• A customer support assistant uses the same model for summarising emails, drafting replies, and classifying incoming requests.
• A software engineering team embeds one model into code review, test generation, and internal documentation search.
• An enterprise search platform uses a shared model to answer questions across HR, IT, and finance content.
• A workflow automation tool relies on one model for extraction, routing, and narrative generation in separate processes.
• A compliance team evaluates whether a vendor’s base model obligations differ from the organisation’s obligations for the deployed application.

The main tradeoff is flexibility versus control. GPAI is attractive because one model can serve many use cases, but that reuse also makes it easier to lose sight of where the model’s inherent behaviour ends and the application’s governance obligations begin.

Security Implications

GPAI creates security issues when organisations assume a generic model can be treated like a static utility. The same underlying model may be exposed to different data types, different user groups, and different instruction patterns, which makes risk management highly context dependent.

Misunderstanding the boundary can lead to weak accountability, incomplete documentation, and inconsistent oversight of outputs that affect business decisions. In operational terms, the failure mode is often not a single catastrophic model issue but a chain of smaller governance gaps: unclear ownership, poor use-case scoping, and missing transparency about what the model can and cannot do.

Because GPAI can be adapted widely, practitioners should watch for overreach, where one model is reused in settings that demand stronger validation than the original deployment assumed. The consequence is usually broader than model error alone. It can include unsafe automation, unreliable decision support, privacy exposure, and difficulty proving compliance when the same base model is embedded in multiple services.

Domain and Governance Relevance

GPAI matters most in AI governance because it creates a split between provider obligations and deployer obligations. That split changes how organisations document model use, assign accountability, and assess whether downstream systems need additional controls beyond the base model.

For NHI and identity-adjacent environments, the significance grows when GPAI is embedded into tooling that can act on behalf of users, administrators, or services. At that point, the model is no longer just producing text or predictions. It may influence access workflows, approval paths, or operational actions, which raises the importance of traceability and permission boundaries.

NHIMG’s guidance is to interpret GPAI through the lens of governance scope first, then operational use. The practical question is not simply whether a model is powerful, but whether its reuse across tasks creates a control boundary that your organisation can still document, monitor, and defend.

Related resources from NHI Mgmt Group

• What should organisations check when a security vendor also uses general-purpose AI tools?
• What breaks when AI trace data is stored in general-purpose databases?
• Why do general-purpose AI tools struggle with security fixes at scale?
• What do organisations get wrong when they assume AI is a general-purpose solution?