An AI use case is not yet a pilot decision
A use case names a possible application. A proof of concept usually tests whether a technical mechanism can work. A pilot observes whether a socio-technical system can operate inside one real, bounded workflow. Moving from one object to the next requires a decision — not a longer idea list.
AURA therefore starts with a business decision that matters but remains limited enough to correct. The team must know who can authorise, suspend and stop the test; which task is being observed; who may be affected; and which new evidence would change the decision.
PILOT, PREPARE, REDESIGN, CONSOLIDATE, PAUSE and STOP are AURA decision states. They are management labels, not regulatory classifications. A STOP decision can be valuable when it prevents a larger, poorly evidenced commitment.
Eight conditions of a bounded AI pilot
A pilot becomes decision-ready only when its commercial, operational, data and human boundaries are visible before testing begins. The following conditions do not certify safety or compliance; they make uncertainty explicit enough for accountable review.
- A business decision and a human owner with authority to suspend or stop.
- An observable workflow rather than a broad ambition such as ‘use AI in sales’.
- Explicit in-scope and out-of-scope tasks, users, data and consequences.
- Permitted, relevant and available inputs, with data provenance understood.
- A baseline describing the current process before AI intervention.
- Acceptance measures and guardrails defined before results are observed.
- Human review, override, correction and escalation routes that work in practice.
- A fixed review point, stop conditions and a viable return to the prior process.
The AURA Bounded Pilot Canvas
Complete this canvas before selecting a tool or vendor. If a field cannot be answered, the next decision is usually PREPARE rather than PILOT. The canvas is an AURA working instrument; it is not a legal opinion, certification or substitute for a sector-specific assessment.
| Field | Decision question | Minimum visible output |
|---|---|---|
| Decision | What decision must this pilot inform? | One sentence and a decision date |
| Owner | Who may approve, suspend and stop? | Named role with authority |
| Workflow | Which task is observed? | Start, end and hand-offs |
| Population | Who uses it and who may be affected? | Users and affected groups |
| Inputs / outputs | What enters and what is produced? | Permitted data and expected output |
| Exclusions | What must the system never do? | Explicit negative scope |
| Baseline | What happens without the pilot? | Comparable current-state measure |
| Evidence | What observation would change the decision? | Primary signal and limitations |
| Guardrails | Which impacts are unacceptable? | Thresholds and escalation |
| Override | How can a human ignore or correct output? | Tested control and fallback |
| Stop conditions | What immediately suspends the test? | Trigger, owner and response |
| Final gate | What happens after review? | PILOT / PREPARE / REDESIGN / PAUSE / STOP |
Measure evidence, not a promised ROI
The NIST AI Risk Management Framework organises risk work around Govern, Map, Measure and Manage. Its Measure playbook recommends context-specific metrics, acceptable performance limits and documentation of what is not measured. AURA uses the same discipline without claiming NIST certification.
A pilot should separate three questions: did the output perform within the tested context; did risks remain within agreed tolerances; and can the organisation operate the controls reliably? A positive answer to one question does not answer the other two.
Start with a baseline, define a primary operational signal and record errors, incidents, near-misses, overrides and missing observations. A positive result supports only the decision written into the pilot. It does not automatically establish ROI, adoption, legal compliance, safety or readiness to scale.
Design the human route before the automated route
Human oversight is not a name on a slide. The assigned person must understand the system’s limits, recognise anomalies, ignore or reverse an output when appropriate, interrupt use and escalate an incident. Those controls must be tested under the same operating conditions as the pilot.
Reversibility means the organisation can pause the test, return to the earlier process, preserve the evidence trail and review what happened without exposing people or operations to disproportionate harm. If the previous process cannot be restored, the initiative may already be too broad for a first pilot.
- Test the override and fallback, rather than assuming they exist.
- Record when humans accept, modify, reject or cannot assess an output.
- Give the stop owner the authority, time and information to act.
- Include incidents and near-incidents in the final decision record.
What Swiss organisations should verify in 2026
Swiss data-protection law already applies to personal-data processing involving AI. The Federal Data Protection and Information Commissioner highlights transparency around purpose, functioning and data sources, and requires a data-protection impact assessment when a planned processing activity is likely to create a high risk for personality or fundamental rights.
Switzerland does not yet rely on one general AI act. Existing data-protection, employment, discrimination, intellectual-property, confidentiality, consumer and sector rules may still apply. Organisations operating in or affecting the European market must assess the EU AI Act separately, including their role and the legal classification of the actual system.
This guide flags questions; it does not determine jurisdiction, risk class or compliance. A specialist legal review is a separate workstream when the context warrants it. Hosting in Switzerland alone does not make a system safe, sovereign or compliant.
Close with a one-page decision record
The pilot ends when the responsible coalition makes a decision, not when a demo looks convincing. The record should show the decision date, sponsor, process owner, tested scope, evidence obtained, limitations, incidents, residual risks, chosen state, next proof, responsible owner and deadline.
PAUSE and STOP records should also state which changed conditions could reopen the question. This makes the choice contestable and revisable without turning every rejected idea into an indefinite backlog.
| Decision | Use when | Required next move |
|---|---|---|
| PILOT | The test is sufficiently bounded and evidence can be collected safely. | Run the approved pilot and keep the fallback active. |
| PREPARE | The opportunity matters, but data, owner, baseline or controls are missing. | Close the named readiness gap first. |
| REDESIGN | The workflow or risk profile is too broad. | Narrow the task, population, data or consequence. |
| PAUSE | A dependency or rule is unresolved. | Set a review trigger and preserve the evidence. |
| STOP | Expected value cannot justify the risk, cost or uncertainty. | Close the initiative and document why. |