Why Your AI Needs a Job Description

Most organisations deploying enterprise AI tools evaluate them on capability. Can it summarise a contract? Can it draft a proposal? Can it answer a technical question accurately? These are reasonable criteria. They are also incomplete ones. The question that gets asked less often is equally important: what will this AI refuse to do, and what happens when someone asks it to step outside its intended scope?

The answer, for most unconstrained AI deployments, is: not much. A general-purpose AI assistant asked to help with an HR performance review will try to help. Asked to draft a legal opinion. It will try to help. Asked to answer questions outside its intended context, by an employee who does not realise that context matters, or by a malicious actor deliberately trying to redirect it, it will try to help. The capability that makes AI assistants useful is the same capability that makes them difficult to constrain.

This is not a model problem. It is an architecture problem. And it has a tractable solution: role-scoped AI behaviour defined and enforced at the deployment level.

What a persona actually does

A persona is not a cosmetic customisation. It is a structured system prompt that defines who the AI is, what it knows, how it behaves, and what it will not engage with. A well-constructed persona for a legal support function tells the AI: here is your role (preliminary contract review support), here is your scope (commercial contracts, non-disclosure agreements, standard terms), here is your constraint (you do not provide advice on matters outside commercial law, you flag anything requiring senior counsel), and here is your tone and format (precise, structured, caveated).

That is not a restriction on capability. It is a specification of role. The same way an employee has a job description that defines what they are responsible for and what falls outside their remit, a persona defines the operating boundaries of an AI system deployed in a specific context. It makes the AI more useful for its intended purpose and significantly harder to redirect to unintended ones.

The security case: personas reduce the prompt injection attack surface

Prompt injection (the use of crafted input to redirect AI behaviour) ranked first in OWASP's LLM Top 10 in both 2024 and 2025 ^[1]. The attack class is simple in concept: if you can get content into an AI's context window, you may be able to convince the AI to treat that content as an instruction rather than data. Documents it is asked to summarise. Emails it is asked to respond to. Webpages it is asked to analyse. Any content the AI processes is a potential injection vector.

Personas do not eliminate prompt injection as a risk. But they materially reduce the blast radius. An AI constrained to a specific domain and role is harder to redirect outside that domain. An attempt to inject instructions into a contract review assistant that push it toward data exfiltration, impersonation, or unintended API calls runs against a defined identity and scope that the persona enforces. The attack still needs to be detected and blocked at the infrastructure layer, but the social engineering component, convincing the AI to deviate, becomes substantially harder. MITRE ATLAS documents persona-boundary violation as a primary enabling factor in successful indirect prompt injection chains ^[2].

The compliance case: consistent behaviour is auditable behaviour

Regulatory frameworks governing AI use (the EU AI Act ^[4], Australia's Privacy Act, sector-specific guidance from APRA and the FCA) increasingly require demonstrable oversight of AI behaviour. Demonstrating oversight requires that AI behaviour be predictable enough to describe, document, and audit. An unconstrained AI assistant that will engage with any query is difficult to document. A persona-scoped AI with defined behaviour is considerably easier.

This matters most in high-risk domains. An AI deployed in an HR function to assist with performance documentation needs to be demonstrably separate from the AI deployed in a finance function for financial modelling. Not because the underlying model is different, but because the deployment context, access to information, and appropriate behaviour are entirely different. Personas make that separation explicit, enforceable, and auditable. Gartner's 2025 analysis of governed vs. ungoverned AI deployments found a 3x higher likelihood of governance failure in unconstrained configurations ^[3].

Department-level personas as governance policy

The most effective enterprise persona deployments treat personas not as individual preferences but as departmental policies. The legal team has a Legal Counsel persona: precise, formally caveated, scoped to commercial and compliance matters, with an explicit reminder that its output does not constitute legal advice. The engineering team has a Code Reviewer persona: focused on code quality, security, and standards adherence, with constraints around what codebases it will discuss. Finance has a Financial Analyst persona with appropriate constraints around what forward-looking statements it will generate.

Each of these is effectively a usage policy encoded in the AI's operating instructions. Unlike an acceptable use policy document that employees are asked to read and acknowledge, a persona-encoded policy is enforced at the point of interaction. The AI does not need to be reminded of its constraints. They are its constraints.

Personas and data access

The governance value of personas extends to knowledge base access. When an AI assistant is connected to internal documentation, client records, or proprietary research, the combination of a scoped persona and appropriate knowledge base configuration defines a coherent access boundary. The Legal Counsel persona has access to legal templates and precedents. The HR persona has access to HR policies and role frameworks. Neither has unrestricted access to the organisation's entire knowledge corpus, and neither should.

Without persona scoping, an AI connected to internal knowledge bases can be queried on any topic, by any user with a login, in natural language. The output of that query is often not distinguishable from authorised output. With persona scoping, the AI's responses are bounded by its defined role and knowledge access. Queries outside that scope are handled by the persona's constraints, not by whatever the AI decides to do with the available context.

Building personas that hold

A persona that can be trivially overridden by a determined user is not a governance control. It is a preference. Effective deployment requires that persona constraints are enforced at the infrastructure level, not merely suggested in a system prompt that users can see and attempt to redirect. The persona should define not just who the AI is in normal operation but what it does when someone attempts to push it outside its defined scope.

• Explicit scope definition: what topics the persona engages with and what it declines
• Role-consistent refusal language: how it declines out-of-scope requests (with a referral path, not a hard no)
• Escalation behaviour: what the AI does when a request touches a sensitive domain (flag for human review, decline, redirect to appropriate contact)
• Tone and format standards: consistent with the department's communication norms and regulatory context
• Constraint language: what the AI will not generate, claim, or assert regardless of how the request is framed