1. Choose a task you can evaluate
Look for a repetitive activity with recognisable inputs and a verifiable output: classifying requests, drafting a reply or extracting fields from documents. Avoid starting with processes where an error could trigger payments, commercial commitments or decisions that are difficult to reverse. The first version should support learning without transferring all responsibility to the system.
Document the current process: its input, owner, output and exceptions. If a simple rule solves the task consistently, you may not need AI. Reserve the model for interpreting language or documents and keep explicit rules for dates, amounts, permissions and states. This makes it easier to understand what went wrong and correct it.
2. Agree data, boundaries and ownership
The NIST AI Risk Management Framework is a voluntary framework for managing AI risks during design, use and evaluation. For a pilot, a practical interpretation is straightforward: document its purpose, owners, boundaries and review criteria. [1]
Map the data entering the workflow, where it is processed, who can access it and how long it is retained. Start with synthetic or prepared test examples, without secrets or unnecessary personal information. Check the chosen provider’s terms for your specific account and contract; do not assume every product handles data in the same way.
3. Design a workflow with a safe outcome
Hypothetical example: support requests arrive by email. AI proposes a category and a draft reply; a person checks both and decides whether to send it. The system records the proposal, corrections and time spent. At this stage it does not delete emails, change contracts or write directly to production data. Human review is a defined step in the process.
Specify what happens when information is missing, a format is unexpected or a request falls outside scope. A useful result may be “requires review”, with a reason. Avoid forcing the model to give a conclusive answer every time. Acceptance rules should be enforced in the code or application running the workflow, rather than depending only on what the model says.
4. Treat documents as data
OWASP describes indirect prompt injection as a risk when external content, such as a file or website, changes a model’s behaviour. Retrieving documents through RAG does not by itself remove that risk. [2]
Separate what the system is allowed to do from what it finds in an email. Give integrations only the permissions they need and keep credentials out of content sent to the model. If the pilot only prepares drafts, it does not need permission to send them. Require a person to confirm consequential actions and record who approved them.
5. Measure with representative examples
Prepare a set of typical cases and exceptions before starting. Include incomplete information, duplicates, ambiguity and the languages your business actually uses. Keep an expected answer or evaluation criterion for each case. Separate examples used to tune the workflow from those used to evaluate it, so that adaptation is not mistaken for general quality.
Measure total time including review, accepted errors, corrections and cost per task. Compare with the previous process on equivalent cases. A quick draft may save no work if reviewing it takes longer than writing it. Define acceptable quality in advance and who decides whether the pilot continues, changes or stops; do not promise a percentage saving before measuring it.
6. Expand only what you have verified
Start with a few people and limited volume. Document how to stop the workflow, return to the manual process and review pending work without executing it twice. Changes to the model, instructions or integrations can affect results: retain versions and run a proportionate evaluation before expanding permissions or volume.
For teams in Barcelona or distributed internationally, test every language they will actually use and agree internal support hours. The pilot should produce an evidence-based decision: continue, adjust the scope or abandon the idea. A useful automation is one the team can supervise, maintain and explain after the initial demonstration.