--- title: "From AI idea to production in five decisions" description: "Five decisions for a pilot that reaches production: problem, data route, control level, acceptance criteria and management after delivery." source_name: "Gen8" source_url: "https://gen8.app/en/kennis/van-idee-naar-productie/" site_home: "https://gen8.app/" source_description: "Managed AI service for SMEs. We set up, connect and manage; you stay in control." locale: "en" authors: - name: "Sasker Soontiëns" url: "https://gen8.app/en/kennis/author/sasker-soontiens/" copyright: "© 2026 Gen8 VOF · Dutch Chamber of Commerce 92978789 · Delft" published_at: "2026-08-22T00:00:00.000Z" modified_at: "2026-10-21T20:22:23.515Z" --- # From AI idea to production in five decisions Most AI pilots never reach production, and rarely because the model fell short. Five decisions — made before building, not afterward — determine whether something remains that people use every day. By Sasker Soontiëns · August 22, 2026 · Decisions and control ## Why a pilot stalls A pilot that works technically but still disappears almost always stalls for the same reason: nobody agreed beforehand when it would be good enough, or who would manage it afterward. The technology was the easy part. The five decisions below cover everything else. ## Decision 1 — Which problem, and why that problem? Choose a high-frequency process with reversible errors. Not the process with the largest annual cost, because that is usually also the process with the most exceptions, the most stakeholders and the slowest feedback. Record what the process currently costs in time per run and in turnaround time. This is a baseline, not a business case; without those two numbers, you cannot demonstrate anything afterward and the discussion becomes a battle of opinions. ## Decision 2 — Where does the data come from, and where does it stay? This decision is often postponed until the security review, which is where pilots fail. Determine beforehand: which systems will be read, whether anything will be written, which data will leave your own environment, how long anything will be retained, and where processing will take place. Processing in the EU is a firm requirement for many organizations; that is a design decision, not a detail to configure later. Also make explicit which data you deliberately *exclude*. A workflow that sees less is easier to approve and easier to explain. ## Decision 3 — What control level for each step? For each step, choose between read-only, proposals with human approval, and automatic execution with a log of every step. This is not a setting you look up later: it determines what the workflow looks like, who is involved and how fast it runs. Almost every step that changes something or sends something externally starts with approval. You change that later, supported by the log of approved and rejected proposals — not on instinct or because approval feels like a delay. ## Decision 4 — When is it good enough? Agree on the acceptance criterion before building, and express it in terms of the user's work, not model metrics. For example: out of a hundred real cases, at least x proposals are approved unchanged, and cases requiring changes take less time than the old process. More importantly, also agree what happens if the criterion is not met. Stopping is a valid outcome and much cheaper than endlessly polishing a pilot because nobody dares to end it. ## Decision 5 — Who will manage this in six months? A production workflow needs an owner who reviews exceptions, someone who intervenes when a source system changes, and an agreement about where the workflow, credentials and logs will reside if the collaboration ends. Arrange this at the start. Afterward it is a negotiation; beforehand it is a paragraph. ## What you gain Four of the five decisions together take a morning and concern agreements, not code. That is the cheapest point at which a pilot can still be canceled — and the only reason a successful pilot then actually keeps running. ## What to do with this Write down the five decisions for the idea currently on the table on one page, before anything is built. The decision you cannot resolve is exactly the conversation you need to have with stakeholders. ## Frequently asked questions How long should a pilot last? As long as needed to meet or miss the acceptance criterion on real cases. A pilot without an end date and without a criterion naturally becomes a project without an owner. Must the pilot run on real data? On real cases, yes, because that is where the exceptions are. That is precisely what makes decision 2 — which data goes where — the first step rather than an after-the-fact formality. What if the organization thinks the control level is too strict? Start strict and change it based on evidence. The log of approved proposals is the argument that lets you release a step later; without that log, every relaxation is a gamble. ## Want to apply this to your own process? Bring one process to a conversation. We assess suitability, risk and the cost of the first step. [Book an introduction]() - Reply within one business day - No obligation