General-Purpose AI (GPAI)

Expanded Definition

General-purpose AI, or GPAI, describes foundation models built to perform many tasks and then adapted across use cases, rather than being trained for a single narrow function. In the EU AI Act, GPAI carries specific provider obligations around documentation, transparency, and downstream information flows, which makes it materially different from ordinary application software. The practical question for NHI and AI governance is not only what the model can do, but who controls the model artefacts, who can modify them, and which obligations travel with the model when it is embedded into another system. This is where the EU AI Act becomes relevant, because its GPAI rules are intended to separate base-model duties from downstream integrator duties. Definitions vary across vendors, and no single technical standard governs GPAI classification yet. The most common misapplication is treating a reused foundation model as “just a component,” which occurs when teams ignore the model provider’s documentation and assume all compliance responsibility sits with the application layer.

Examples and Use Cases

Implementing GPAI rigorously often introduces governance overhead, requiring organisations to weigh deployment speed against traceability, disclosure, and change control.

• A product team embeds a multilingual GPAI model into a support assistant and must preserve model documentation, usage limits, and safety notes for the downstream operator.
• An enterprise fine-tunes a general model for internal knowledge retrieval and needs clear separation between provider obligations and its own system-level controls, as described in the DeepSeek breach analysis.
• A security team evaluates whether a model endpoint is exposed with credentials, because GPAI access paths can become high-value targets when secrets are mishandled, a pattern discussed in The State of Secrets in AppSec.
• A procurement group requests model cards, training-data summaries, and update cadence details before allowing a GPAI service into regulated workflows.
• A platform team applies the EU AI Act interpretation to determine whether it is acting as a provider, deployer, or both.

Why It Matters in NHI Security

GPAI matters in NHI security because the model itself can become part of the trust boundary, especially when API keys, service tokens, or orchestration privileges allow broad model access. NHIMG research shows that 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, which is a practical reminder that GPAI can amplify secret exposure if governance is weak. The issue is not limited to training data; it also includes prompt injection, retrieval abuse, and uncontrolled tool access inside agentic workflows. In a regulated environment, the EU AI Act and related governance expectations push organisations to document where the model ends and the operational system begins. That distinction becomes critical when secrets are reused across environments or when an external GPAI service receives sensitive prompts. Organisations typically encounter model governance failures only after a leakage, misuse, or incident review, at which point GPAI classification becomes operationally unavoidable to address.

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?