Lorenza.
The Intent Brief
for AI applications.

Each row: persona name, role and tenure, technical fluency, working environment, primary motivation.

At launch versus 12 months out. This drives almost every infrastructure decision.

Each row: use case name, description, pre-condition, post-condition. Use cases drive scope; vague ambitions sink it.

Things people will ask for that the system explicitly will not do. Naming these now prevents scope creep later.

Particularly relevant for LATAM deployments where Spanish, Portuguese, and English often coexist.

Where the user encounters the system.

Beyond WCAG, particularly relevant for AI: screen-reader handling of streamed responses, keyboard navigation through suggestions, color-independent confidence signals.

Most apps blend two or three; identify all that apply.

Has the organization committed to a provider, or is this open?

What the system must explicitly NOT do, even if technically possible. Often a regulatory, ethical, or brand constraint. Naming these is as important as naming what it will do.

How catastrophic is a confident-sounding wrong answer? This determines guardrails, evaluation rigor, and whether human review is mandatory.

Must the same input always produce the same output? Critical for audit, reproducibility, regulatory contexts.

Most enterprise apps don't need it. Confirming early prevents architectural over-investment.

How will quality be measured before launch and monitored afterward?

Especially critical for any system affecting people's access to services, credit, employment, or care.

Each row: system name, data type, owner / steward, access method. Be specific.

All formats the system will handle.

Order of magnitude: documents, rows, GB, hours of audio, etc.

How recent must the data be for answers to be useful?

Honest assessment. The right answer is rarely "excellent."

What rules must input data adhere to before it enters the AI pipeline?

What's the most sensitive data the system will touch?

Where is the data legally required to live? Particularly relevant for LATAM (LGPD Brazil, Habeas Data Colombia, México LFPDPPP), EU (GDPR), and regulated sectors globally.

Has anyone confirmed the organization has the right to feed this data into models — including third-party providers?

How users prove who they are.

Often mandated separately from SSO method.

How permissions are structured. Affects every read of data.

If the system serves multiple business units, customers, or organizations.

How user state, conversation context, and authenticated sessions persist.

In transit, at rest, and for sensitive fields.

Where API keys, model credentials, and database secrets live.

AI-specific attack surface. What's the strategy for hostile users trying to manipulate the model? Often missed entirely in traditional security reviews.

Are you allowed to send personal data to a third-party model? If not, what's the redaction strategy?

How long full prompt/response transcripts are kept.

Should the system learn about each user across sessions, or treat every interaction as fresh?

For regulated environments, every AI decision may need to be reconstructable years later: input, prompt version, retrieved context, raw model output, post-processing, final user-facing output.

GDPR, LGPD, and similar regimes require deletion of personal data on request — including from prompts, embeddings, and logs.

RPO (recovery point objective) and RTO (recovery time objective).

Each row: system, protocol, frequency, owner. Systems the AI app must read from.

Each row: system, action triggered, format, owner. Systems the AI app writes to or triggers actions in.

Formats, volumes, and frequency for one-time or periodic data loads.

What users and downstream systems need to extract. Formats, scheduling, access control.

Will this system expose APIs for others to consume?

Real-time push of AI events to external systems.

How should integration failures be handled? Retry strategy, fallback, rollback, notification.

Per day at launch and at year 1. Distinguish interactive (user-initiated) from batch.

Simultaneous users at the busiest moment. Drives infrastructure sizing.

User-perceived response time tolerance. AI inference is slower than traditional apps; expectations must be set early.

Token-by-token streaming dramatically improves perceived latency. Not all integrations support it.

Per-user, per-month or per-transaction limit. Forgetting this is how enterprise AI bills surprise CFOs.

Semantic cache, prompt cache, embedding cache — each cuts cost differently.

High-level shape of the system. Drives team structure, deployment complexity, and cost profile.

Where users access from. Drives latency, residency, and provider region selection — particularly for multi-country LATAM deployments.

Every framework that touches the use case. Be exhaustive.

Per EU AI Act framing, useful even outside Europe.

Where human review is mandatory before AI output reaches end recipient.

When the AI says "no," can someone explain why?

How users are informed about AI involvement and consent to data processing.

Approval process for new AI providers, model versions, and prompt changes in production.

Each row: risk description, likelihood, impact, mitigation, owner. Honest naming halves the risk.

Availability, latency p95/p99, error rate.

Where the system runs, including AI inference.

Logging, metrics, tracing, AI-specific telemetry (token usage, hallucination flags, eval scores).

What gets paged, who gets paged, on what conditions. AI systems need new alert types beyond traditional infra.

How code, prompts, and model configurations are tested and deployed.

Who handles tier-1, tier-2, tier-3 issues. AI issues often require new triage skills.

In-product way for users to flag bad outputs. Fuel for continuous improvement.

Strategy for deploying new prompts, model versions, and features without breaking trust.

What happens when the model goes off the rails — degrades, hallucinates badly, gets jailbroken.

How the AI presents itself. Formal, friendly, neutral, branded.

When the AI surfaces information, how does the user verify the source?

How the system signals when it's uncertain.

Required by emerging regulation in many jurisdictions. Always tell the user when they're interacting with AI.

How the system communicates when it can't help. Often the difference between trusted and abandoned.

Each row: milestone, target date, status (committed / aspirational / blocked).

Roles assigned and gaps. AI builds need product, engineering, data, ML, security, legal, change management.

Other teams, vendors, decisions, or events the project waits on.

What the business commits to internal users or external customers.

Anything this discovery surfaced that needs a separate working session.

Anything else the engineering team should know going into this build.