Belgian SMEs do not need a hundred-page AI policy before they test an internal agent. They do need a clear operating agreement before an AI system reads customer data, drafts supplier messages, updates a CRM, recommends HR actions, or influences financial decisions. Without that agreement, the first pilot often creates the same questions in every meeting: who owns the output, what data may be used, when must a person approve the action, and how will errors be found?
A lightweight AI governance policy answers those questions before the agent goes live. It is practical, short, and tied to actual workflows. The goal is not to slow experimentation. The goal is to make experimentation safe enough that a Belgian management team can keep using what works, stop what does not, and prove that controls exist when customers, employees, auditors, or partners ask.
Why governance has to start before the pilot
Many AI projects begin as tool trials. A team connects a model to email, documents, tickets, or CRM notes and quickly sees useful output. That speed is attractive, but it also means risk appears before the organisation has named an owner. The agent may see personal data, produce advice that sounds authoritative, use outdated knowledge, or create records that look like a human decision.
The EU AI Act sets a wider regulatory frame for AI systems in Europe, including obligations that depend on risk category, transparency, human oversight, data governance, and documentation. Most SME workflow agents will not be high-risk systems, but the regulation is still a useful signal: governance is becoming an operating discipline, not an optional legal appendix. The Belgian Data Protection Authority also treats AI as a data-protection topic when personal data is involved, which is common in customer service, HR, sales, finance, and operations.
NIST's AI Risk Management Framework uses four plain verbs: govern, map, measure, and manage. That sequence works well for SMEs. Decide who is accountable, map the actual workflow and data, measure quality and risk, then manage the system after launch. A small company can do that without creating a heavyweight compliance programme.
The minimum policy: seven decisions
A useful Belgian SME policy can fit into seven decisions. Each one should be specific enough that a project team can apply it without asking for a new interpretation every week.
- Purpose: name the workflow and the business outcome. "Improve support" is too broad. "Draft first responses to Belgian customer support tickets for human approval" is specific.
- Owner: name the business owner, technical owner, and review cadence. The vendor, model provider, or automation platform is not the accountable owner.
- Data boundary: list the systems, document stores, and fields the agent may read or write. Mark personal data, confidential data, and information that must be excluded.
- Human control: define what the agent may do alone, what it may only draft, and what it must escalate.
- Evidence: require logs for prompts, source records, outputs, approvals, and final actions where the risk justifies it.
- Quality threshold: define the sample test, acceptance criteria, and known failure cases before launch.
- Stop rule: decide who can pause the workflow when output quality, privacy, security, or customer impact becomes uncertain.
These decisions are enough to prevent the most common failure: a promising agent that no one can safely move from demo to production because the boundaries were never agreed.
Map the workflow, not the model
Governance should begin with the workflow. A Belgian manufacturer, consultancy, retailer, or professional-services firm may use the same model API, but the risks differ by process. A knowledge assistant that answers internal policy questions has different controls from an agent that prepares customer quotes or updates supplier records.
Map the trigger, input data, source of truth, decision points, approvals, exceptions, and final system of record. Then decide where AI is useful. In many SME workflows the agent should classify, extract, summarise, draft, or recommend. It should not silently approve spend, change employment records, promise delivery dates, or override customer terms unless the business has designed explicit controls for those actions.
This is the same discipline Intyb uses when assessing workflow automation and custom AI solutions. The model is only one component. The operating design includes permissions, integrations, approval gates, exception handling, audit logs, and reporting.
Set data rules that people can follow
Data rules should be written for the people who build and operate the workflow. Start with allowed sources. For example: the support agent may read the helpdesk ticket, approved knowledge base, product catalogue, and order status fields, but not unrelated CRM notes or private finance documents. A sales research agent may use public website information and approved CRM fields, but not scrape personal social profiles without a lawful basis and business approval.
Next, define retention and access. Who can see the prompt logs? How long are outputs stored? Can a vendor use data for training? Are model calls processed inside the EU, or is a transfer assessment needed? For personal data, involve the person responsible for GDPR compliance early. A simple data table is often enough for a first pilot: source, data type, purpose, access role, retention, and exclusion rule.
Permissions matter as much as policy text. If a document store is over-permissioned, an AI assistant can expose information that employees should not see. Before connecting SharePoint, Google Drive, a CRM, or an ERP, review whether the underlying access model reflects the business reality.
Design human oversight as a workflow step
"Human in the loop" is weak unless the loop is designed. A reviewer needs the source information, the agent's recommendation, confidence or uncertainty signals where available, and a clear approve, edit, reject, or escalate action. The final record should show whether the human accepted the output or changed it materially.
Use stricter oversight for workflows that affect money, customer commitments, employee data, legal obligations, or safety. A low-risk internal summarisation workflow may need sample review. A finance workflow that drafts invoice exceptions should require approval before any accounting record changes. A customer-facing support agent should have escalation rules for complaints, cancellations, regulated claims, and uncertainty.
Good oversight also protects adoption. Employees are more likely to use an AI workflow when they understand where responsibility sits and how to challenge a wrong answer. Treat feedback as part of operations, not as a side channel.
Measure quality before and after launch
A lightweight policy should require a test set before production. Use real or representative examples, including ordinary cases, edge cases, and known failure modes. For a support draft agent, test answer accuracy, source grounding, tone, escalation, language handling, and privacy. For a knowledge assistant, test whether the answer cites the approved source and says "I do not know" when the source is missing.
After launch, measure both value and control quality. Useful metrics include handling time, first-response time, correction rate, escalation accuracy, rejected drafts, customer satisfaction, privacy incidents, and failed workflow runs. Review samples on a schedule. If the workflow changes, the test set should change too.
A Belgian SME does not need to make statistical claims before a small pilot, but it should know the baseline and the guardrails. If the agent saves time while increasing corrections, complaints, or risky approvals, the implementation is not ready to scale.
A practical rollout sequence
Start with one contained workflow in Belgium or Brussels where the data is available, the owner is engaged, and the risk is proportionate. Draft the seven policy decisions. Review the data boundary. Build the smallest useful version. Test it against a representative sample. Run it with human approval. Review results after the first operating cycle, then decide whether to expand, revise, or stop.
This sequence pairs well with the Brussels AI workflow readiness scorecard. The scorecard helps decide whether a workflow is ready; the governance policy defines how the ready workflow may operate. For the opposite risk, read why bad process automation costs more: unclear process ownership becomes more expensive when software moves faster.
For Belgian businesses, the most useful governance is visible in the workflow itself: named owners, limited data, clear approvals, tested outputs, and a stop rule. To review one candidate workflow with those controls in mind, contact Intyb's Brussels AI implementation team or explore our work for Belgian companies.