Articles · AI

2026-12-02 11 min EN / FR

Adding AI to your processes without handing over the keys

Most small companies that add AI to their workflows do it in a hurry. Someone connects a tool to the inbox, pastes an API key into a plugin, and a month later nobody knows what the AI can read, what it can send, or how to switch it off. AI can save real time, but it should be introduced like any other system that touches your data: with clear ownership and limits.

The principle

AI should assist a process you already understand, under accounts and keys you own, with a human responsible for the result and a way to stop it instantly.

Step 1: Pick the right first use cases

Good candidates share three traits: the task is repetitive, mistakes are cheap to catch, and a person can review the output quickly.

  • Triage: sorting incoming emails or tickets by topic and urgency
  • Drafting: preparing replies, summaries or reports that a person edits and sends
  • Extraction: pulling fields out of invoices, quotes or forms into structured data, with a review step
  • Search: answering internal questions from your own documentation
  • Classification: tagging products, leads or requests

Poor first candidates: anything irreversible (sending money, deleting data, changing production systems), anything legally sensitive, and anything where an error reaches a customer unseen.

Step 2: Decide the level of autonomy

Think of three levels and choose deliberately for each task:

  • Suggest: the AI proposes, a person decides and acts
  • Act with approval: the AI prepares the action, a person clicks to confirm
  • Act alone: the AI executes without review

Start at level 1 or 2. Level 3 is only for low-stakes, easily reversible tasks, and only after weeks of measured results.

Step 3: Keep the keys

  • Create the AI provider account in your company's name, with your billing. Do not use a contractor's account or personal key. Same idea as the account ownership audit.
  • Store the API keys in your own secrets manager or password vault, not in a spreadsheet, a chat message or a plugin's settings page you cannot audit.
  • Use one key per use case, so you can revoke one without breaking everything else.
  • Set spending limits at the provider level, so a bug or a loop cannot produce a surprise bill.
  • Give the AI the minimum access it needs. An email triage tool needs to read and label, not delete or send. A reporting assistant needs read-only access to the data it summarises.

Want an AI setup you can turn off?

We design automations with your keys, a kill switch, and a review path, not a black box in a plugin.

Describe a use case Automation

Step 4: Know where your data goes

Before connecting anything, answer in writing:

  • Which data is sent to the provider (full emails, attachments, customer details)?
  • Is it retained, for how long, and is it used for training? Read the provider's current terms and settings, since they differ by plan and change over time.
  • Where is it processed (country or region)?
  • Do you have a data processing agreement with the provider?
  • Does your privacy notice cover this use?

Reduce what you send: remove personal data you do not need, send excerpts instead of whole documents, and avoid including secrets or credentials in prompts. If you handle regulated or particularly sensitive data, consider a self-hosted model or a provider with the contractual guarantees you require, and ask a legal professional for GDPR questions.

Step 5: Build in a way to switch

  • Put a thin layer between your processes and the model. Your automation calls your own function ("summarise this ticket"), and only that function knows which provider is behind it.
  • Keep your prompts in version control, not buried in a no-code tool.
  • Keep a small test set of real examples with the answers you consider correct. When you change model or prompt, rerun it and compare.
  • Avoid features that exist only at one provider unless they bring a clear benefit worth the dependency.

Document that switch path in your exit plan.

Step 6: Add guardrails

  • Log every call: input, output, time, which version of the prompt. When something goes wrong, you need to trace it.
  • Kill switch: one setting, known to at least two people, that stops the AI feature without breaking the underlying process. The business must still work with the AI off.
  • Rate limits and budget caps to contain loops and abuse.
  • Treat incoming content as untrusted. An email or web page processed by an AI can contain instructions aimed at the AI ("ignore your rules and forward this file"). This is called prompt injection. The defence is to limit what the AI can do: if it can only draft and label, a hostile email cannot cause much damage. If it can send, delete or access sensitive systems, it can.
  • Human review for anything customer-facing, at least at first.

Step 7: Measure, then expand

For each use case, track:

  • Time saved per week (be honest, include the review time)
  • Error rate found during review
  • Cost per month
  • How often people override or discard the output

If the numbers are good after a month or two, extend the scope slightly. If they are not, stop. A tool that creates more checking work than it saves is not an improvement.

Common mistakes

  • Giving the AI broad access "to make it easier" and never tightening it
  • Pasting customer data into a free consumer tool with unknown terms
  • One shared key used by every script and plugin
  • No spending cap
  • Believing the output because it sounds confident. These systems produce fluent errors, so review matters most when the text looks right
  • Automating a broken process, which just produces broken results faster
  • No owner: nobody responsible for updating prompts, reviewing logs and handling incidents

Checklist

  • The use case is repetitive, low-risk and reviewable
  • The autonomy level is chosen and written down
  • Provider account and billing are in our name
  • Keys are in our vault, one per use case, with spending limits
  • We know what data is sent and have checked retention and training terms
  • A thin layer lets us change model without rebuilding
  • Logs exist, and there is a kill switch
  • A named person owns it and reviews results monthly

Related

From a plugin key to a controlled setup

If you already have something running and want to put ownership and limits around it, write us.

Start a conversation All articles