DEV Community: Dr Hernani Costa

Coimbra Tech Founders: AI Governance Over AI Tools

Dr Hernani Costa — Mon, 07 Sep 2026 06:57:50 +0000

When your founding team came from research, AI consulting needs are inverted. You don't need tool training—you need governance architecture that doesn't slow your regulatory pathway, product intelligence that connects technical output to what European buyers purchase, and operational AI that frees your team to focus on product rather than compliance administration.

TL;DR: AI consulting for Coimbra tech companies and university spin-offs. Governance, product intelligence, and EU compliance for B2B and health-tech founders.

Coimbra's technology cluster has a profile that does not map cleanly onto any generic AI consulting playbook. The University of Coimbra and Instituto Pedro Nunes (IPN) have produced a steady flow of deep-tech and health-tech spin-offs, many founded by researchers who are technically sophisticated but commercially early. Alongside these spin-offs sit B2B software companies targeting European enterprise buyers and a growing number of digital health companies operating under both the Medical Device Regulation (MDR) and the EU AI Act. Why this matters: the AI consulting needs of a Coimbra tech founder are specific to this context. Generic AI adoption advice built for a retail SME in Lisbon or a manufacturing company in Braga does not apply here.

The Coimbra Founder Profile and Why It Changes the Consulting Approach

Most Coimbra tech founders came into their companies through a research pathway. They hold technical depth in their domain, whether that is biomedical engineering, computer vision, NLP, or materials science. What they typically need from an AI consultant is not technical capability transfer; they already have that. What they need is three things: governance design that does not slow their regulatory pathway, AI strategy that connects their technical output to what a European enterprise buyer actually purchases, and operational AI that frees their small team to focus on the product rather than internal administration.

This distinction matters for how you should evaluate any consulting engagement. A consulting firm that leads with AI tool training or automation workshops is solving the wrong problem for most Coimbra tech companies. The higher-value work is in the intersection of compliance architecture, product intelligence, and go-to-market AI strategy.

Compliance Context: MDR, EU AI Act, and GDPR as a Sales Requirement

Coimbra's health-tech spin-offs face a regulatory stack that is more complex than most European mid-sized companies encounter. If your product or a component of it is a medical device or an AI-assisted medical device, you are operating under MDR 2017/745, and if that product includes AI decision support, under the EU AI Act as a high-risk AI system under Annex III.

The practical implication: your AI governance documentation is not an internal nicety. It is a prerequisite for CE marking, a prerequisite for hospital procurement conversations, and increasingly a prerequisite for health system pilots in Germany, France, and the Netherlands, which are Coimbra spin-offs' most common initial European markets outside Portugal.

For B2B SaaS founders serving European enterprise buyers, the compliance pressure is different but equally concrete. GDPR is now a selling requirement, not a background obligation. Enterprise procurement teams at companies in Germany, the Netherlands, and the Nordics routinely include data processing agreement reviews, AI usage disclosure requirements, and sub-processor chain verification in their vendor due diligence. A Coimbra B2B SaaS company that cannot produce a clear, accurate answer to "which AI models process our data, under what legal basis, and where?" is losing deals it may not even know it lost.

The consulting work here is not writing the GDPR policy. It is designing the data processing architecture so the honest answer to that question is one your buyers can accept.

AI Use Cases Relevant to Coimbra Tech Companies

The AI use cases that generate the most value for Coimbra tech companies fall into four areas, each with a different risk and effort profile.

Product intelligence. For spin-offs with a software product, AI can accelerate the feedback loop between user behaviour and product decisions. Usage pattern analysis, churn signal detection, and feature prioritisation models built on your own product data are low-risk, high-value, and do not require external AI providers to touch sensitive customer data. This is typically the first area where a founder-led company sees measurable ROI from an AI consulting engagement.

Customer success automation. For B2B SaaS companies with a small customer success function covering a growing customer base, AI can handle first-pass ticket triage, renewal risk flagging, and onboarding progress monitoring. The governance requirement here is clear scope definition: the AI surfaces information and drafts responses; a human sends them. This is a straightforward human-in-the-loop design that a small operations team can manage.

Internal operations. Research-origin companies frequently have inefficient internal operations because the founding team's attention has been on the product. Meeting summarisation, document drafting, literature monitoring, and internal knowledge retrieval are areas where AI tools can return meaningful time to technical founders without touching regulated data or requiring complex compliance work.

AI feature development for software products. Some Coimbra companies are building AI capabilities into their own products. Here the consulting need shifts to AI product strategy: which capabilities to build vs buy, which model providers to use given your data residency requirements, how to document AI-assisted features for your own customers' compliance teams, and how to structure the human oversight layer inside your product so your customers can satisfy their own regulatory obligations.

What a Structured AI Consulting Engagement Looks Like for a Coimbra Tech Company

A well-structured engagement for a professional services firm or founder-led company in Coimbra's ecosystem typically runs in three stages.

The first stage is a structured assessment of your current AI exposure: what AI tools are already in use across the company (often more than founders realise), what data those tools touch, and where your regulatory obligations apply. For health-tech companies, this assessment explicitly maps against MDR and EU AI Act high-risk criteria. For B2B SaaS companies, it maps against the data processing questions your buyers will ask.

The second stage is a governance and architecture design: the policies, the technical controls, and the documentation you need to operate AI responsibly and demonstrate that to customers and regulators. This is not a large overhead for a company that does it once correctly; it becomes a significant overhead for companies that build it reactively in response to a lost deal or a regulatory query.

The third stage is implementation support for the highest-value AI use cases identified in the assessment, with the governance layer already in place so each new use case is additive rather than requiring a compliance review from scratch.

Frequently Asked Questions

Is AI consulting relevant to a Coimbra company that already has strong technical AI capability?

Yes, for two reasons. First, technical AI capability and AI governance design are different skills; most technical founders underestimate the governance work until they face a procurement questionnaire or a regulatory review. Second, the go-to-market and operational AI use cases that return time to the founding team are often lower priority internally but generate significant value.

How does the EU AI Act affect health-tech spin-offs in Coimbra specifically?

If your product includes AI that makes or supports clinical decisions, it is likely classified as a high-risk AI system under Annex III. This means you need a conformity assessment, documented human oversight mechanisms, and a post-market monitoring plan before you can legally place the product in the EU market. The MDR and EU AI Act requirements overlap in some areas but are not identical; specialist guidance on where they interact is worth securing early.

What should a B2B SaaS founder in Coimbra do first?

Map which AI tools your team currently uses and what data each one processes. Then assess whether your standard customer contracts and data processing agreements accurately reflect that map. Most growing software teams discover a gap between what their contracts say and what their tools actually do. That gap is the first risk to close.

Written by Dr Hernani Costa | Powered by Core Ventures

Originally published at First AI Movers.

Technology is easy. Mapping it to P&L is hard. At First AI Movers, we don't just write code; we build the 'Executive Nervous System' for EU SMEs.

Is your architecture creating technical debt or business equity?

👉 Get your AI Readiness Score (Free Company Assessment)

Our AI Readiness Assessment for EU SMEs maps your current AI exposure, identifies governance gaps before they cost you deals, and prioritises the highest-value use cases for your specific context—whether you're a health-tech spin-off navigating MDR and EU AI Act compliance, a B2B SaaS company facing enterprise procurement scrutiny, or a research-origin company building AI into your product.

Copilot Studio Agents: The Governance Layer Before Autonomous Action

Dr Hernani Costa — Sun, 06 Sep 2026 06:57:41 +0000

When a Copilot Studio agent sends an email, updates a customer record, or triggers a payment workflow, it acts in your name—and the liability stays with you, not Microsoft. Under the EU AI Act (in force since August 2024, active enforcement since January 2026), organisations deploying AI agents capable of consequential autonomous action must maintain documented human oversight mechanisms. This article provides the decision matrix and Power Automate configuration pattern that satisfies both regulatory requirements and operational risk management.

TL;DR

Which Copilot Studio agent actions need human approval gates, how to configure them in Power Automate, and what EU AI Act auditors expect.

When a Copilot Studio agent sends an email on behalf of your sales team, updates a customer record, or triggers a supplier payment workflow, it is acting in your name. If it acts incorrectly, the liability stays with you, not Microsoft. Why this matters: the EU AI Act, in force since August 2024 and under active enforcement since January 2026, requires that organisations deploying AI agents capable of consequential autonomous action maintain documented human oversight mechanisms. A decision matrix built before deployment is the minimum required artefact. This article gives you that matrix, plus the Power Automate configuration pattern that implements it.

What Human-in-the-Loop Actually Means in a Copilot Studio Context

Human-in-the-loop (HITL) is not a product feature; it is a governance principle. In a Copilot Studio deployment, it means that a defined class of agent-initiated actions cannot proceed without a human reviewing the proposed action, confirming or rejecting it, and that rejection is logged.

Copilot Studio agents trigger actions through Power Automate cloud flows. The agent calls a flow; the flow executes steps (read data, write data, send messages, call APIs). HITL sits inside that flow as an approval step, typically using the Power Automate Approvals connector, which routes a request to a named approver, waits for a response within a configurable timeout, and branches on approval or rejection.

The critical distinction: HITL is not the same as a confirmation prompt inside the Copilot Studio conversation. A chat confirmation is a UX courtesy. A Power Automate approval gate is a governance control with a durable audit log. Auditors will ask for the latter.

The Four Action Categories and Their Risk Profiles

Every action a Copilot Studio agent can take falls into one of four categories. Your governance design should treat each category differently.

Category 1: Read-only retrieval. The agent fetches data and surfaces it to a human. Examples: pulling a CRM record, summarising a support ticket thread, generating a report. Risk: low. HITL: not required. Documentation required: data access scope, log of what was retrieved and when.

Category 2: Reversible write actions. The agent creates or updates a record where the change can be corrected within the same business day without financial or legal consequence. Examples: updating a task status in Planner, adding a note to a CRM contact, creating a draft email (not sending). Risk: moderate. HITL: recommended for first 90 days of deployment, then optional if error rates are below your defined threshold. Documentation required: action log with originating agent session ID.

Category 3: Consequential, partially reversible actions. The agent sends a communication on behalf of a named employee, updates a contract record, modifies a pricing field, or triggers a workflow that notifies an external party. Examples: sending a customer email via Outlook, submitting a purchase order request, updating invoice status. Risk: high. HITL: mandatory. Configuration pattern: Power Automate approval step with a 4-hour timeout; if no response, the action is cancelled and the requesting user is notified, not auto-approved. Documentation required: approval decision, approver identity, timestamp, action payload.

Category 4: Irreversible or high-consequence actions. The agent initiates a financial transfer, publishes content externally, modifies access control permissions, or deletes records. Risk: critical. HITL: mandatory, with dual approval for actions above defined thresholds (for example, any financial action above EUR 500). Documentation required: as above, plus a pre-action risk classification log showing the agent correctly identified the action as Category 4 before requesting approval.

The Decision Matrix

Use this matrix to classify actions before you build any flow.

Action Type	Reversible?	External Party Affected?	Financial Impact?	Required Gate
Read or summarise data	Yes	No	No	None
Create internal draft	Yes	No	No	None
Update internal record	Yes	No	No	Log only
Send internal notification	Yes	Internal only	No	Log only
Send external communication	Partial	Yes	Possible	Single HITL approval
Update contract or pricing record	Partial	Yes	Yes	Single HITL approval
Trigger external workflow or API	Partial	Yes	Possible	Single HITL approval
Initiate payment or financial action	No	Yes	Yes	Dual HITL approval
Modify access permissions	No	Yes	Possible	Dual HITL approval
Delete or archive records	No	Internal/External	Possible	Dual HITL approval

Configuring HITL in a Power Automate Flow: The Pattern

The Power Automate Approvals connector implements the core gate. The configuration pattern for a Category 3 action follows these steps inside the flow.

First, before the consequential action step, insert a Start and wait for an approval action. Set type to "Approve/Reject: First to respond" for single approval, or "Approve/Reject: Everyone must approve" for dual approval. Assign approvers by role (not by name where possible, to survive staff changes). Set timeout to your agreed SLA, typically 4 hours for business-day actions.

Second, add a Condition branching on the approval outcome. On the "Approved" branch, proceed with the original action. On the "Rejected" branch, send a notification to the requesting user with the rejection reason and log the decision.

Third, add a Compose action at both branch endpoints that writes a structured log record: timestamp, approver, decision, action payload summary, and the Copilot Studio session ID. Write this to a SharePoint list or Dataverse table that your compliance team can query. This log is your audit trail.

One operational detail that growing software teams frequently miss: set the approval timeout to cancel, not to auto-approve. An unanswered approval request is not implicit consent; it is an unresolved governance event.

What the EU AI Act Requires for Autonomous Agents

Under the EU AI Act, AI systems that take autonomous actions affecting individuals or business operations are classified based on risk. Custom agents built in Copilot Studio that send communications, update records, or trigger financial workflows will, in most deployments, fall into the limited risk category at minimum, and potentially high risk if they operate in regulated domains such as HR, finance, or health.

For limited risk systems, the Act requires transparency: the person affected must be able to know they are interacting with or being acted upon by an AI system. For high-risk systems, the requirements are more specific: human oversight must be technically implemented (not just policy-stated), the system must be capable of being stopped by a human, and a conformity assessment is required before deployment.

The HITL approval gate described above satisfies the technical human oversight requirement. The audit log satisfies the documentation requirement. What it does not replace is the risk classification exercise: you must formally assess whether any of your agents operate in a high-risk domain before you deploy.

For operations leaders at mid-sized companies and founder-led companies who have not completed that classification, this is the starting point, not the approval flow configuration.

What Auditors Will Ask For

When an auditor, a customer's procurement team, or your own compliance officer reviews a Copilot Studio deployment, expect three questions. First: which actions can the agent take without human confirmation, and how did you decide that was acceptable? Your decision matrix answers this. Second: show me an example of the approval flow working, including a rejection. Your Power Automate run history answers this. Third: how do you know the agent is not taking Category 3 or 4 actions and misclassifying them as Category 1? Your action log, with agent session IDs, answers this.

If you cannot produce all three answers in under 30 minutes, your governance design is incomplete.

Frequently Asked Questions

Does every Copilot Studio agent need a HITL approval layer?

No. Read-only agents that retrieve and surface information without writing or sending anything do not require approval gates. HITL is required when the agent can take actions that affect external parties, create financial obligations, or cannot be easily reversed.

Can we use Copilot Studio's built-in confirmation step instead of a Power Automate approval flow?

The in-conversation confirmation is a UX control, not a governance control. It produces no durable audit log and cannot be reviewed by a third party. For EU AI Act compliance purposes, it does not satisfy the human oversight requirement.

What happens if no one approves the request before the timeout?

Configure the timeout to cancel the action and notify the requesting user. Never configure auto-approval on timeout; that removes the governance control entirely.

How often should we review which actions are in which category?

Review the decision matrix whenever you add a new agent capability, change the data sources available to an existing agent, or change the business process the agent supports. A quarterly review as part of your AI governance cycle is a reasonable minimum for most small businesses and mid-sized companies.

AI Procurement Checklist: Healthcare Buyer's $500k Risk Window

Dr Hernani Costa — Sat, 05 Sep 2026 06:57:50 +0000

Signing an AI vendor contract without compliance documentation is like deploying an unvalidated clinical tool—your liability exposure begins the moment you execute. This checklist closes that window.

TL;DR: 15-point vendor questionnaire for healthcare SMEs buying AI systems in Europe. Covers MDR, EU AI Act, GDPR, and clinical validation requirements.

Before your clinic, hospital department, or healthcare operations team signs a contract for an AI system, there is a specific window when your leverage is highest: the procurement moment. Why this matters is straightforward. Once the contract is signed, the data processing agreement is in place, and the system is live, your ability to impose compliance requirements on the vendor drops sharply.

This checklist is for that window. It is not a general EU AI Act overview. It is a buyer-side tool for operations leaders, procurement managers, and hospital administrators at small and mid-sized healthcare organisations evaluating a specific vendor or product right now. It covers the six documentation categories you must address before any signature, and it closes with a 15-point vendor questionnaire you can send verbatim.

Who This Is For

This applies to founder-led clinics, growing healthcare operations teams, and small business healthcare providers across Europe procuring any AI system that touches: clinical decision support, patient triage, diagnostic imaging analysis, administrative automation using patient records, or any system processing special category health data under GDPR Article 9.

If the AI system your organisation is evaluating touches any of those categories, all six documentation areas below apply.

Six Documentation Areas Before Any Signature

1. EU AI Act High-Risk Classification

The EU AI Act classifies AI systems used in healthcare that influence clinical decisions as high-risk (Annex III, point 5). Before signing, you need to confirm the vendor's own classification and whether that classification has been independently reviewed.

Ask the vendor:

Has this system been classified under the EU AI Act? Under which category?
If high-risk: has a conformity assessment been completed, and by which notified body?
Is a CE mark under the EU AI Act in progress, issued, or not applicable, and why?

A vendor who cannot answer these questions in writing is a vendor whose compliance posture you cannot verify. For professional services firms or mid-sized companies handling patient data at scale, an unverifiable compliance posture is a procurement-ending condition.

2. Medical Device Regulation (MDR) Status

AI systems that meet the EU definition of a medical device fall under MDR (EU 2017/745). Many clinical AI tools, including diagnostic support systems and image analysis tools, are medical devices regardless of how the vendor markets them.

Ask the vendor:

Is this system classified as a medical device under MDR? If not, on what basis is it excluded?
If classified: what is the device class (I, IIa, IIb, III), and what is the notified body?
Is the Declaration of Conformity available for inspection before contract signature?

The intersection of MDR and EU AI Act creates a dual compliance obligation for high-risk AI medical devices. Your legal counsel should review both before signature.

3. Data Processing Agreement Requirements

Under GDPR Article 28, any vendor processing personal data on your behalf must sign a Data Processing Agreement (DPA) before processing begins. For special category health data under Article 9, the DPA requirements are stricter and non-negotiable.

Your DPA must specify:

Subject matter, duration, and purpose of processing
Categories of data subjects and types of personal data
Vendor's obligations (confidentiality, security, sub-processor controls)
Data subject rights support (access, erasure, portability)
Breach notification timeline (72 hours to you; you then notify the supervisory authority)

Do not accept a vendor's standard template without review. Most vendor DPA templates are written to protect the vendor, not the healthcare organisation. For small businesses and growing healthcare operations teams without in-house legal capacity, a one-hour review by a GDPR-specialist solicitor at this stage is significantly cheaper than a supervisory authority investigation later.

4. Training Data Provenance

The data used to train a clinical AI system directly affects its reliability and potential bias. European healthcare buyers have the right to ask, and high-quality vendors will have documentation ready.

Ask the vendor:

What datasets were used to train this model?
Were those datasets collected with appropriate consent for AI training purposes?
What is the geographic and demographic distribution of the training data?
Has the model been validated on European patient populations specifically?

A system trained primarily on North American patient data and applied to European clinical populations carries demographic validity risk that may not be visible in the vendor's headline accuracy figures.

5. Clinical Validation Evidence

For any AI system involved in clinical workflows, you need prospective or retrospective clinical validation evidence, not just technical performance metrics.

Request:

Peer-reviewed publications or clinical study reports validating the system's performance
Sensitivity and specificity data for the clinical use case you are procuring for
Any known failure modes or population subgroups where performance degrades
Post-market surveillance data if the system has been deployed for more than 12 months

A vendor who offers only internal benchmarks without independent clinical validation is asking you to make a clinical governance decision based on marketing data. For hospital administrators at small clinics, the liability exposure of deploying an unvalidated clinical AI tool is not a risk worth accepting for a faster procurement process.

6. Incident Response Obligations

Under NIS2 (for entities in scope) and GDPR, your organisation has breach notification obligations. Your AI vendor's incident response obligations must be contractually specified before you can meet yours.

Your contract must include:

Vendor notification to you within 24 hours of any security incident affecting your data
Definition of what constitutes a reportable incident
Vendor's incident response contact (name, not just a helpdesk email)
Post-incident root cause analysis obligation
Business continuity and system recovery time commitments

The 15-Point Vendor Questionnaire

Send this verbatim as part of your procurement process. Request written responses. Verbal assurances at a demo are not compliance documentation.

EU AI Act and MDR Classification

Under the EU AI Act, how is this system classified? If high-risk, which conformity assessment procedure has been followed?
Is this system a medical device under MDR (EU 2017/745)? If yes, what is the device class and notified body? If no, what is the regulatory basis for exclusion?
Is the Declaration of Conformity (MDR) or EU AI Act technical documentation available for review prior to contract signature?

Data Processing and GDPR

Will you sign our Data Processing Agreement, or do you require us to sign yours? (Note: we require our DPA as the minimum baseline.)
Which sub-processors will have access to our patient data? Are they all located within the EEA, or are there third-country transfers? If third-country: what transfer mechanism applies?
What is your breach notification timeline to us as the data controller?
How do you support data subject rights requests (access, erasure, portability) relating to data processed through your system?

Training Data and Clinical Validation

What datasets were used to train this model, and were those datasets collected with appropriate consent for AI training purposes?
What is the demographic and geographic distribution of the training data? Has the model been validated on European patient populations?
Can you provide peer-reviewed publications or independent clinical study reports validating performance for our specific use case?
What are the known failure modes or population subgroups where model performance degrades?

Security and Incident Response

What is your contractual commitment for notifying us of a security incident affecting our data? (We require 24 hours or less.)
Who is the named incident response contact at your organisation for our account?
What is your system's recovery time objective (RTO) and recovery point objective (RPO) in the event of a system failure?

Ongoing Obligations

If you update the AI model after contract signature (retraining, architectural changes), what is your obligation to notify us, and do we have a right to re-evaluate before the updated model is applied to our data?

What to Do With the Responses

Score each response against three criteria: specificity (is it a concrete answer or a deflection?), documentation (is there a document you can review, or only a verbal assurance?), and contractual commitment (is it in the contract or just in the sales conversation?).

Any question answered with "we can discuss that in implementation" or "our standard terms cover that" should be treated as a red flag. The implementation phase is after signature. You need answers before.

For procurement managers at mid-sized companies without a dedicated legal or compliance team, the threshold for proceeding without specialist review should be low: if more than two of the 15 questions receive deflection responses, bring in a healthcare IT legal specialist before proceeding.

Frequently Asked Questions

Does this checklist apply to AI tools we build internally, or only to vendor products?

If your organisation commissions a custom-built AI system from a software development partner who will process patient data, the same documentation requirements apply: the development partner is a data processor under GDPR, the system may still be a medical device under MDR, and the EU AI Act applies to the deployer (your organisation) regardless of who built the system.

We are a small clinic with limited procurement resources. Do we really need all 15 questions answered?

Yes, but you can sequence them. Questions 1-3 (classification) and 4-7 (data processing) are non-negotiable before any contract discussion continues. Questions 8-11 (clinical validation) and 12-15 (incident response) should be resolved before contract signature. A vendor who refuses to answer any of the first seven questions is not a vendor you should be contracting with, regardless of the product's capabilities.

What if the vendor is a large company with an established European presence? Can we trust their standard compliance documentation?

Vendor size and market presence do not substitute for contract-specific documentation. Large vendors often have standard compliance packs that do not reflect the specific configuration, data flows, or use case of your deployment. Request documentation specific to your contract, not the vendor's generic compliance overview.

How does NIS2 interact with these procurement obligations?

If your healthcare organisation is in scope for NIS2 (the revised Network and Information Security Directive, mandatory for essential entities including certain healthcare providers from October 2024), you have additional obligations around supply chain security. This means vendor security posture is not just a GDPR question: it is a regulatory obligation. Your vendor questionnaire responses on incident response (questions 12-14) feed directly into your NIS2 supply chain risk assessment.

Copilot Checkpoints: EU AI Act Compliance Risk in 5 Gates

Dr Hernani Costa — Fri, 04 Sep 2026 06:57:46 +0000

Uncontrolled Copilot deployments create silent compliance exposure. Most European mid-sized companies treat Microsoft 365 Copilot rollout as complete once emails draft themselves and meeting summaries auto-generate. Under EU AI Act requirements for high-risk adjacent systems and general-purpose AI governance, you need documented evidence that humans reviewed AI outputs at defined workflow checkpoints—not just at project end.

TL;DR: Build structured review gates into your Microsoft 365 Copilot rollout. Five practical checkpoints across email, docs, Teams, Excel, and SharePoint.

Your Microsoft 365 Copilot is live. Emails are being drafted, meeting summaries are appearing in Teams, and Excel is generating data insights your finance team used to spend hours producing manually. This matters because most European mid-sized companies stop there, treating the deployment itself as the finish line. It is not.

The gap between a Copilot rollout and a governed Copilot rollout is exactly where EU AI Act compliance risk accumulates. Under the Act's requirements for high-risk adjacent systems and general-purpose AI, your organisation needs documented evidence that humans reviewed AI outputs at defined points in your workflows, not just at the end of a project cycle. A 5-minute checkpoint at the right moment is worth more than an hour of post-hoc review.

This article gives operations leaders and IT managers at small businesses and growing software teams a concrete checkpoint design: which Copilot use cases need a formal review gate, what that gate looks like in practice, and how to log it in a format your compliance officer will recognise.

Why Checkpoints, Not Just Final Review

Final review is insufficient for AI-assisted workflows because errors compound. If Copilot drafts a client proposal based on a misread SharePoint document, and no one checks the source attribution before the draft reaches the approver, the approver is reviewing polished prose built on a flawed foundation. They are likely to approve it.

Workflow checkpoints interrupt compounding. They are structured pauses where a named human confirms a specific aspect of the AI output before it moves to the next stage. The checkpoint does not replace the final review. It makes the final review meaningful.

For mid-sized companies operating under GDPR and increasingly under EU AI Act scrutiny, checkpoints also produce the audit trail that regulators expect: who reviewed what, when, and what action they took.

The Five Checkpoint Areas for Microsoft 365 Copilot

1. Email Drafting: The Send-Gate Review

Copilot in Outlook drafts emails based on your prompt and conversation context. The risk is tone, commitment, and factual accuracy, particularly in client-facing or regulatory communications.

Checkpoint design: Before sending any Copilot-drafted email to an external recipient, the sender completes a three-second mental scan using a fixed checklist embedded in your email policy:

Does this commit the company to anything not yet approved?
Is the tone appropriate for this specific recipient?
Are any figures or dates accurate?

For professional services firms handling client accounts, this checkpoint should be explicit policy, not implied good practice. Log it by requiring senders to add a tag (for example, "Copilot-reviewed") to the sent email, which your IT team can report on monthly.

What to log: Sender, recipient category (internal/external/client), date, Copilot tag confirmed.

2. Document Generation: The Source-Trace Gate

Copilot in Word and PowerPoint can generate documents from prompts referencing your SharePoint content. The most common failure mode is citation drift: Copilot surfaces content from an outdated document version, or synthesises across documents in a way that loses the original context.

Checkpoint design: Before any Copilot-generated document is shared beyond its author, a designated reviewer (this can be the author themselves for low-stakes documents) checks:

Can every factual claim be traced to a named source document?
Is that source document the current version?
Does the structure match the intended use case (proposal, policy, briefing)?

For founder-led companies without dedicated compliance staff, build this into your document naming convention. A document that has not passed the source-trace gate carries a prefix like "DRAFT-AI" until it does.

What to log: Document name, reviewer name, date reviewed, source documents confirmed, gate outcome (approved/revised/rejected).

3. Teams Meeting Summaries: The Accuracy-and-Action Gate

Copilot in Teams generates meeting summaries and action item lists. These are operationally high-risk because people act on them. A misattributed action item, or a decision recorded incorrectly, creates downstream confusion that can take days to unwind.

Checkpoint design: Within 2 hours of any meeting where Copilot generated a summary, the meeting organiser (not Copilot) reviews and confirms:

Are all action items attributed to the correct person?
Are any decisions accurately captured, including the reasoning?
Is anything missing that was agreed verbally but not in the transcript?

The organiser then sends the confirmed summary, not the raw Copilot output. This is the distribution checkpoint: Copilot output is internal until the organiser confirms it.

What to log: Meeting date, organiser, confirmation timestamp, any corrections made (yes/no, and if yes, category: attribution/decision/omission).

4. Excel Data Analysis: The Assumption-Disclosure Gate

Copilot in Excel can generate analysis, identify trends, and create formulas. The failure mode is hidden assumptions: Copilot may interpret a column header differently than your analyst intended, or apply a calculation logic that is technically correct but contextually wrong.

Checkpoint design: Before any Copilot-generated Excel analysis is used in a decision or shared with leadership, the analyst who requested it confirms:

What assumption did Copilot make about the data structure? (This is visible in the Copilot conversation pane.)
Is that assumption correct for this dataset?
Has the formula or analysis been spot-checked against at least two manual data points?

For operations leaders using Excel for financial modelling or forecasting, add a second reviewer for any analysis feeding into decisions above a defined threshold (for example, budget decisions over 10,000 EUR).

What to log: File name, analyst name, Copilot assumption confirmed (yes/no), spot-check completed (yes/no), second reviewer if applicable.

5. SharePoint Search and Synthesis: The Access-Scope Gate

Copilot can search across your SharePoint environment and synthesise content from multiple documents. This creates two risks: it may surface documents the user was not intended to see (a permissions configuration issue), and it may synthesise across documents in ways that produce misleading composite answers.

Checkpoint design: This checkpoint operates at two levels.

At the administrative level (quarterly): Your IT manager or operations lead reviews Copilot access logs to confirm that the SharePoint permissions model is functioning as intended. Are users seeing only the document libraries they should have access to? Have any unexpected cross-site retrievals occurred?

At the user level (per synthesis request): When a user asks Copilot to synthesise across multiple documents (for example, "summarise our last three client project reports"), they should verify the source list Copilot used before acting on the output. Copilot surfaces this in the response.

What to log (admin level): Review date, reviewer, access anomalies found (yes/no), remediation actions if applicable.

Building the Log: A Lightweight Format

Growing software teams and small businesses do not need a dedicated compliance platform to log Copilot checkpoints. A shared SharePoint list with five columns covers the requirement:

Date
Checkpoint type (email/document/meeting/excel/sharepoint)
Reviewer name
Gate outcome (approved/revised/rejected)
Notes (optional, for anomalies)

This log serves two purposes. First, it gives your compliance officer evidence of human oversight for EU AI Act purposes. Second, it gives your operations lead a monthly data point: how often are Copilot outputs being revised at each checkpoint? A high revision rate in one category (for example, Teams meeting summaries consistently requiring correction) signals a configuration or training issue worth addressing.

What This Does Not Cover

Workflow checkpoints address the human-oversight layer. They do not replace the governance framework that sits above them: your AI use policy, your data classification rules, and your incident response procedure. If you have not yet documented those, the checkpoint log will have no policy anchor to reference.

For the governance layer, see the AI Governance Framework for European SMEs and the Microsoft 365 Copilot Governance guide. For the incident layer, the AI Incident Response Playbook covers what to do when a checkpoint failure causes a real problem.

Frequently Asked Questions

How many checkpoints do we realistically need to implement at once?

Start with the two highest-risk areas for your specific operation. For most mid-sized companies, that means email (external communications) and Teams meeting summaries (action-item accuracy). Add document generation and Excel analysis checkpoints in month two. SharePoint access-scope review can be scheduled quarterly from day one.

Do checkpoint logs need to be retained for a specific period under EU AI Act rules?

The EU AI Act does not yet specify a universal retention period for general-purpose AI oversight logs. However, GDPR data processing records are typically retained for the duration of the processing activity plus a reasonable buffer. A two-year retention policy for Copilot checkpoint logs is a defensible starting position for most European professional services firms.

What if our team sees checkpoints as bureaucracy and stops doing them?

This is the most common failure mode in Copilot governance. The fix is integration, not enforcement: build the checkpoint into the existing workflow rather than adding a separate step. The email tag, the document naming prefix, the 2-hour summary confirmation window: these are nudges that fit the existing process. If a checkpoint requires a separate form or system login, adoption will collapse within 30 days.

Does this apply to Copilot used internally only, or also to Copilot outputs shared with clients?

Both, but with different urgency levels. Client-facing outputs (proposals, reports, emails) carry higher reputational and legal risk and should have the strictest checkpoints. Internal-only outputs (meeting notes, internal briefings) warrant lighter checkpoints but still need the basic review gate and log entry.

EU AI Act Enforcement Active: $15M Fine Risk & SME Checklist

Dr Hernani Costa — Thu, 03 Sep 2026 06:57:52 +0000

EU AI Act enforcement is no longer theoretical—it's operational, and your compliance window is closing. National market surveillance authorities across France, Germany, and the Netherlands began formal compliance reviews in Q1 2026, with fines reaching 3% of global annual turnover (minimum EUR 15 million) for high-risk AI system violations. For European SMEs deploying AI in recruitment, credit decisions, or education assessment, the August 2026 grace period deadline transforms compliance from a future concern into an immediate operational liability.

EU AI Act Enforcement Is Active: What Q1 2026 Brought and What to Check Now

TL;DR: EU AI Act enforcement began January 2026. Here is what happened in Q1 and a 10-point checklist for European SMEs to verify now.

The EU AI Act moved from policy document to enforcement reality on 2 February 2026. For most European SME founders and compliance managers, the question is no longer "what does this law say" but "what do I need to verify this week." Why this matters: national market surveillance authorities have begun their first formal compliance reviews, and the 6-month grace period for existing AI systems in high-risk categories closes in August 2026. A growing software team or professional services firm that has been treating this as a future concern now has a concrete deadline with concrete consequences. This article covers what actually happened in Q1 2026, which obligations are active now, and a 10-point checklist you can walk through before the grace period closes. This is not a general EU AI Act overview. There are already numerous articles covering the basics. This covers the enforcement phase specifically.

One reference number to keep in mind: fines for violations of high-risk AI system obligations can reach 3% of global annual turnover, with a minimum floor of EUR 15 million for larger organisations.

What Happened in Q1 2026: The Enforcement Landscape

The first quarter of 2026 established several important precedents for how enforcement is unfolding in practice.

National authorities activated their oversight structures. By March 2026, France (CNIL leading AI Act coordination), Germany (national AI authority under the BNetzA umbrella), and the Netherlands (Autoriteit Persoonsgegevens with extended AI mandate) had all issued their first compliance guidance documents for businesses operating in their jurisdictions. These documents clarified which sectors were receiving initial scrutiny attention.

Priority sectors for early compliance review. Q1 enforcement attention concentrated in three areas: HR and recruitment software (specifically automated CV screening and candidate scoring tools), credit and insurance underwriting tools used by financial services providers, and AI systems used in education assessment. SMEs using off-the-shelf tools in these categories were included in scope, not just the software vendors. This is the key point many small business owners missed: if you use a third-party AI tool for recruitment or credit decisions, you carry compliance obligations alongside the vendor.

The prohibited practices ban took effect in February. Article 5 prohibitions came into force on 2 February 2026. These cover social scoring systems, real-time biometric surveillance in public spaces (with narrow law enforcement exceptions), and AI systems that exploit psychological vulnerabilities to influence behaviour. No enforcement actions against SMEs were publicly confirmed in Q1 on these grounds, but several large platform operators received formal inquiries.

High-risk obligations timeline confirmed. The compliance obligations for high-risk AI systems under Article 6 and Annex III are on a phased schedule. For systems placed on the market after the Act's entry into force, obligations are immediate. For existing systems already in use, the grace period runs until August 2026 for most categories. Embedded AI systems (AI built into machinery covered by other product regulations) have until 2027.

What SMEs told regulators they were confused about. Several national business associations published Q1 surveys of their members. The most common confusion points were: whether using a third-party AI product (as opposed to building one) creates obligations; whether internal-only AI tools are in scope; and how to classify a system that performs multiple functions, some of which might be high-risk and some not.

The short answers: yes, deployers carry obligations not just providers; internal tools are in scope if they affect people's rights or access to services; and a mixed-function system is classified by its highest-risk component.

What Article 6 High-Risk Classification Means in Practice

Article 6 is the classification mechanism. It routes AI systems into the high-risk tier based on two pathways.

Pathway 1 covers AI systems that are themselves safety components of products regulated by existing EU law (machinery, medical devices, vehicles). If your AI is embedded in a regulated product, it is high-risk by definition.

Pathway 2 covers the Annex III list: employment, education, access to essential services, law enforcement, migration, and certain justice and democratic process applications. For European SME operators, the most practically relevant Annex III categories are:

Recruitment and employment management tools that make or substantially influence hiring, promotion, or performance assessment decisions
Access to credit and insurance (scoring and pricing tools)
Access to education and vocational training (assessment of students and candidates)

If your organisation uses AI tools that fit these descriptions, even as a deployer of a third-party product, you are subject to the high-risk compliance obligations listed below.

The "substantially influences" language is important. A tool that produces a ranked list of candidates which a human manager then uses to make a hiring decision has been interpreted by legal experts as substantially influencing that decision. Do not assume that having a human in the final approval step removes your obligations.

For the governance framework that should sit behind these compliance obligations, see the AI Governance Framework for European SMEs.

The 10-Point Compliance Checklist for European SMEs

This checklist covers the obligations that are either already active or closing before August 2026. Walk through it before the grace period ends.

1. Inventory your AI tools. List every AI system your organisation uses, including tools embedded in software you already pay for (CRM AI features, HR platform AI, finance tool automation). You cannot classify what you have not listed.

2. Classify each tool. For each tool on your list, determine whether it falls into an Annex III category. When in doubt, assume high-risk and verify. The cost of a classification assessment is lower than the cost of an enforcement inquiry.

3. Check your vendor agreements. For third-party AI tools in high-risk categories, your vendor should provide technical documentation and conformity information. If they cannot, that is a risk signal. Update your procurement process to require this for future contracts.

4. Verify human oversight mechanisms. For every high-risk system, document the human oversight process. Who reviews outputs before they affect a person? How does a person contest an AI-influenced decision? These processes must exist and be documented, not just implied.

5. Check your transparency notices. If any AI system your organisation uses interacts with people or affects their access to services, those people need to know. Review your customer communications, employee policies, and applicant-facing processes for AI disclosure statements.

6. Update your GDPR records. AI systems that process personal data for automated decisions require entries in your GDPR records of processing activities. If your AI inventory from step 1 reveals tools not listed there, update your records now.

7. Assess your high-risk logging setup. High-risk AI systems must maintain logs sufficient to trace their operation. Check whether your vendor provides this, or whether you need to implement it at the deployer level.

8. Document your bias and accuracy monitoring. High-risk systems require ongoing performance monitoring. If you are using an employment or credit AI tool, what is your process for detecting and responding to evidence of bias or systematic error?

9. Assign accountability. Every high-risk AI system needs a named person responsible for its compliance. This does not require a full-time AI compliance officer in a founder-led company, but it does require a designated owner with authority to pause the system if something goes wrong.

10. Set your August 2026 review date. If you have existing high-risk systems covered by the grace period, put the compliance review date in your calendar now. The grace period closes, and the obligations become immediately enforceable from that date.

For existing monitoring infrastructure, the AI Compliance Monitoring Checklist for European SMEs and the Monthly AI Governance Review Template for SMEs give you repeatable processes to maintain compliance posture after the initial setup.

Which SME Use Cases Attracted Early Compliance Attention

Based on Q1 regulatory guidance and published inquiry summaries, three SME use case patterns appeared most often in early compliance discussions.

Automated CV screening in recruitment. Several HR software products used by small and mid-sized companies include AI ranking and filtering features that default to "on." Many operators were unaware these features were active. If your HR platform includes AI screening, verify whether it is in use and classify it accordingly.

AI-powered credit limit decisions in B2B contexts. Some accounts receivable and trade credit platforms include AI-driven credit limit assignment. Operators using these tools as deployers carry obligations even though they are not the software vendor.

AI content moderation affecting access to platforms. For mid-sized companies running online platforms or communities, AI moderation tools that can restrict user access may fall under the access-to-services category in Annex III.

For sector-specific compliance context, see the AI Governance in Financial Services for European SMEs article, which covers the financial services obligations in more detail.

What the Fractional CTO or External Adviser Angle Looks Like

Many European SMEs do not have an in-house legal or compliance team with AI expertise. The Q1 enforcement picture suggests that regulators are not expecting small business owners to be AI law experts. They are expecting that operators made a reasonable effort to understand their obligations and acted on that understanding.

A structured one-day compliance review with an external AI adviser, followed by documented decisions on each tool in your inventory, is likely sufficient to demonstrate that reasonable effort. The Fractional AI Governance Consultant vs In-House AI Lead piece covers the build-vs-buy decision for ongoing compliance capacity.

If you discover an incident or near-miss while doing this review, the AI Incident Response Playbook for European SMEs covers what to do next, including notification obligations.

Frequently Asked Questions

Does the EU AI Act apply if I only use off-the-shelf AI tools and do not build anything?

Yes. The Act distinguishes between providers (who build and place AI systems on the market) and deployers (who use AI systems in their business operations). Deployers of high-risk AI systems carry their own set of obligations, separate from those of the provider. Using a third-party tool does not transfer compliance responsibility to the vendor.

What happens if I miss the August 2026 grace period deadline?

The grace period is a practical accommodation for existing systems. After it closes, national market surveillance authorities can initiate enforcement proceedings against non-compliant high-risk AI systems without any additional notice period. Fines for high-risk system violations are set at up to 3% of global annual turnover. The grace period exists to give operators time to comply, not to defer compliance indefinitely.

How do I know if a system "substantially influences" a decision?

This is an active area of regulatory interpretation, but the working test used in Q1 guidance documents is this: if a human decision-maker would materially change their decision without the AI output, the system substantially influences the decision. A ranked list, a score, a recommendation, or a flag all qualify. Disclosure of information without ranking or recommendation is less likely to qualify.

Agentic AI Workflows: EU SME Governance Before Deployment

Dr Hernani Costa — Wed, 02 Sep 2026 06:57:48 +0000

Autonomous AI systems are already running in European mid-sized companies. Your governance model, liability exposure, and staffing assumptions are all changing simultaneously—and most operators aren't prepared.

Most conversations about agentic AI sound like they belong in a research lab, not a 25-person professional services firm in Amsterdam or a growing software team in Warsaw. That is a problem, because agentic AI is already being deployed in European mid-sized companies, and the operators who understand it earliest will set the pace for their sector. Why this matters: when AI shifts from answering questions to completing multi-step tasks without constant human input, your governance model, your liability exposure, and your staffing assumptions all change simultaneously. This guide is not a technical explainer. It is a translation for operations leaders and founders who need to know what agentic AI actually does differently, which use cases are viable for a founder-led company in 2026, what the EU AI Act says about automated decision systems, and what you should put in place before you deploy anything.

One concrete starting point: an agentic AI system might receive the instruction "process all inbound supplier invoices, flag anomalies above 5%, and draft a response for any that need clarification." A standard LLM chatbot would help you write that response once you asked for it. An agentic system executes the chain from end to end.

What "Agentic" Actually Means (Without the Hype)

The term covers a specific capability shift. A standard LLM responds to a single prompt and stops. An agentic AI system takes a goal, breaks it into sub-tasks, executes those sub-tasks in sequence (sometimes in parallel), uses tools like web search or databases along the way, checks its own output, and loops until the goal is met or it hits a stopping condition.

Think of it as the difference between a skilled contractor who answers your questions and one you can hand a project brief to. The second one still needs oversight. But the scope of delegation is fundamentally different.

Three components define most agentic systems in production today:

Planning: The system decomposes a goal into ordered steps without being told what the steps are.

Tool use: The system can call external APIs, query databases, read and write files, or trigger actions in third-party software.

Memory and state: The system tracks what it has already done within a session, and in some architectures, across sessions.

For a small business operator, the practical implication is this: agentic AI can handle processes that previously required a human to sit in the middle, making routing decisions at each step. That is valuable. It is also where the governance complexity begins.

Which SME Use Cases Are Ready in 2026

Not every agentic use case is equal. Some are mature, well-tested, and safe to deploy in a European mid-sized company today. Others require more infrastructure than most SMEs have.

Document processing workflows are the most mature category. Invoice routing, contract review for standard clauses, proposal generation from structured briefs, and compliance document summarisation all work well with current agentic tooling. The reason: the input and output formats are predictable, errors are detectable, and a human can audit outputs efficiently.

Customer triage and first-response is viable but requires a clear escalation policy written before you deploy. Agentic systems can classify inbound requests, pull relevant account history, draft a personalised first response, and route to the right team. The governance requirement is explicit: which decisions can the system make autonomously, and which require human sign-off?

Internal operations automation covers a wide range: meeting notes to action items, CRM updates from call transcripts, internal knowledge base queries, and onboarding document preparation. These are lower-risk because the outputs stay internal and errors are caught by the people they affect.

Financial decision support (budgeting scenarios, supplier comparison, cash flow modelling) is worth exploring but should stay in an advisory mode for most operations leaders. The system proposes; a human decides. This matters for EU AI Act compliance, which we cover below.

Use cases that are not ready for most SMEs in 2026: anything that makes autonomous hiring, firing, or performance-ranking decisions; any system that interacts directly with customers in a regulated sector without a human review layer; and any deployment where the system can move money without a human approval step.

What Changes in Your Workflows When You Deploy Agentic AI

Four things shift immediately, and you need to account for all of them before go-live.

Decision accountability moves upstream. With a chatbot, a human reads the output and decides what to do. With an agentic system, decisions are embedded in the chain. Before deployment, you need to document which decisions the system is authorised to make, under what conditions it must pause and escalate, and who is accountable when it gets something wrong.

Error surfaces multiply. A single-prompt LLM can produce a bad answer. An agentic system can make a bad decision at step 3, act on it in steps 4 and 5, and compound the error before anyone notices. Your quality assurance process needs to account for chain failures, not just output failures.

Data access scopes become a liability question. Agentic systems need broad data access to be useful. That same access creates exposure if the system is compromised or behaves unexpectedly. Principle of least privilege applies here as it does in any IT security context: the system should have access to exactly what it needs for each task, no more.

Staff roles shift, not disappear. The most realistic near-term outcome for a growing software team or professional services firm is that agentic AI handles the routing and assembly steps in a process, and human staff handle judgment, client-facing decisions, and quality review. This is worth communicating clearly to your team before deployment, not after.

What the EU AI Act Requires for Automated Decision Systems

The EU AI Act, which entered enforcement in January 2026, distinguishes between AI systems that assist humans and those that make or substantially influence decisions that affect people. For European SME operators, three obligations are most relevant.

High-risk classification: If your agentic system is used in hiring, credit assessment, access to essential services, or certain safety-critical processes, it likely falls under the high-risk category defined in Article 6. High-risk systems require conformity assessments, technical documentation, human oversight mechanisms, and registration in the EU database before deployment.

Transparency requirements: Even for lower-risk systems, if the agentic AI interacts with people (customers, job applicants, employees in ways that affect their status), those people have a right to know they are interacting with an automated system.

Human oversight by design: The Act requires that high-risk systems include mechanisms for human intervention. For agentic systems, this means building in pause points, escalation triggers, and override capabilities as system features, not afterthoughts.

The practical implication for a founder-led company: if your agentic deployment touches HR, customer credit, or anything that could be classified as access to a service, get a proper classification assessment done before you deploy. The cost of getting this wrong, including enforcement fines and reputational exposure, is significantly higher than the cost of a pre-deployment compliance review.

For more detail on building the governance layer, the AI Governance Framework for European SMEs covers the structural requirements, and the AI Use Policy Template for European Employees gives you a starting document for internal AI rules.

What to Put in Place Before You Deploy

Five things every European operations leader should complete before running an agentic AI system in production:

1. Decision inventory: List every decision the system will make autonomously. For each one, state who is accountable, what the error rate threshold is before the system pauses, and who reviews flagged outputs.

2. Data access map: Document which data sources the system can read and write. Confirm this against your GDPR records of processing activities.

3. Escalation protocol: Define the conditions under which the system stops and routes to a human. Build these into the system configuration, not the user documentation.

4. Staff briefing: Tell your team what the system does, what it does not do, and how to override it. Agentic AI deployed without staff awareness creates both operational risk and employee trust problems.

5. Audit log: Ensure every action the system takes is logged with enough detail to reconstruct what happened if something goes wrong. This is a requirement under the EU AI Act for high-risk systems and good practice for all others.

If you are not sure whether your planned deployment qualifies as high-risk under the EU AI Act, the AI Compliance Monitoring Checklist for European SMEs is a useful starting point.

Frequently Asked Questions

Is agentic AI only for large enterprises with big technical teams?

No. The tooling has matured enough that a mid-sized company without a dedicated AI team can deploy agentic workflows for document processing and internal operations using platforms that require configuration rather than custom development. The governance work is the harder part, and it scales with your organisation size, not against it.

How do I know if my planned use case counts as high-risk under the EU AI Act?

The Act lists high-risk categories in Annex III. They include employment and worker management, access to essential services, credit scoring, and certain safety-related systems. If your use case touches any of these areas, assume high-risk until a proper classification assessment says otherwise. The AI Governance Framework for European SMEs includes a classification walkthrough.

What is the most common mistake SMEs make when deploying agentic AI?

Deploying without a decision inventory. Operators focus on what the system can do and underestimate how many routing decisions are embedded in the workflow. When something goes wrong, there is no clear record of what the system was authorised to do, which makes both the fix and any regulatory response significantly harder.

Copilot Data Leaks: The $50k GDPR Fine Before Deployment

Dr Hernani Costa — Tue, 01 Sep 2026 06:57:42 +0000

Commercial Hook: Microsoft 365 Copilot ships with your Microsoft 365 license—but without governance, it becomes a data exposure vector. European SMEs deploying Copilot without a GDPR data access review face regulatory fines, employee privacy violations, and uncontrolled AI surfacing of confidential information.

TL;DR: European SME governance checklist for Microsoft 365 Copilot. GDPR data access, EU AI Act obligations, and what to lock down before deployment.

Microsoft 365 Copilot is one of the most widely deployed enterprise AI tools in Europe. It ships as part of the Microsoft 365 E3 and E5 licensing tiers and is available as an add-on for business plans. For many European SMEs, the decision to adopt it is effectively made when the IT department upgrades the Microsoft 365 licence.

The governance question comes after the licensing question, and it is often asked too late. Copilot surfaces data from across the Microsoft 365 tenant: emails, SharePoint documents, Teams conversations, calendar data. It generates outputs from that data. Without governance, that means Copilot can surface information to users who should not have access to it, include confidential content in AI-generated outputs, or process personal data in ways that conflict with GDPR requirements.

This page explains what European SMEs need to lock down before Copilot reaches end users, what the EU AI Act says about Copilot use, and how an AI governance assessment supports a clean deployment.

What Copilot actually accesses

Understanding the scope of Copilot's data access is the starting point for governance. Microsoft 365 Copilot accesses:

Emails in Exchange Online (sent, received, calendar invites)
Documents in SharePoint and OneDrive that the user has access to
Teams messages and meeting transcripts (when transcription is enabled)
Dynamics 365 data (if integrated)
Data from connected Microsoft Graph APIs

The critical word is "has access to." Copilot operates on the permission model of the Microsoft 365 tenant. If a user has broad SharePoint access because permissions were never tightened after a historical project, Copilot will be able to surface content from that access.

For most SMEs, the honest answer to "who has access to what in our Microsoft 365 tenant?" is "we are not entirely sure." That is the governance problem Copilot makes visible.

The GDPR data access problem

GDPR requires that personal data is accessed only by those with a legitimate purpose. A Copilot query that surfaces HR documents, personal employee data, or customer PII in response to a business question is a potential GDPR issue, even if the user who received the output was nominally authorized to access some of those documents.

Before Copilot deployment, European SMEs should complete a data access review covering three questions:

What data does the tenant contain? A Microsoft Purview scan identifies sensitive data types (personal data, health data, financial data) across the tenant and where they are stored.
Who has access to it? An access rights review (often called a SharePoint permissions audit) maps which users and groups can access which document libraries. Most SMEs discover overly broad access during this step.
Should Copilot be able to surface it? For particularly sensitive categories (HR records, M&A information, board communications, client PII), the answer is often no. Microsoft Purview sensitivity labels can be used to restrict Copilot from surfacing content with specific labels.

This review takes 1-3 weeks for a 30-50 person company, depending on how well-structured the tenant permissions are.

EU AI Act obligations for Copilot deployers

Microsoft positions Copilot as a general-purpose AI tool. Under the EU AI Act, general-purpose AI tools are not automatically high-risk. However, the obligations depend on how Copilot is used.

If Copilot is used to assist in decisions about individual employees (performance assessment, disciplinary review, promotion recommendations), that use case falls under Annex III (employment and workers management) and triggers high-risk AI obligations.

For typical business use cases (drafting emails, summarizing documents, generating meeting notes), Copilot is likely to be minimal-risk or limited-risk under the EU AI Act.

The practical governance step for the EU AI Act is:

Identify which Copilot use cases are planned or in use.
Assess whether any fall into Annex III categories.
For any high-risk use case, document the intended purpose, the human oversight mechanism, and the review cadence.
Maintain an AI systems inventory that includes Copilot and its use cases.

The seven governance checkpoints before deployment

A structured governance checklist for Microsoft 365 Copilot deployment at a European SME:

1. Data access review complete: Purview scan done, sensitive data labeled, overly broad SharePoint access corrected.

2. Sensitivity labels configured: HR documents, board materials, M&A data, and client PII labeled to restrict Copilot surfacing.

3. Data processing agreement reviewed: Microsoft publishes a Data Processing Agreement (DPA) for Microsoft 365. Confirm it covers EU data residency requirements for your organization.

4. Copilot use case inventory: document which use cases are approved (drafting, summarizing, meeting notes) and which are not (employment decisions, clinical decisions, financial credit decisions).

5. User training completed: users need to understand that Copilot outputs are AI-generated, may contain errors, and must be reviewed before external use. A 30-minute training session covers the basics.

6. Feedback and incident channel defined: users need a way to report problematic Copilot outputs (hallucinated information, unexpected data surfacing). This can be a shared Teams channel or a simple email address.

7. Review cadence set: schedule a quarterly governance review to check whether the use case inventory is current and whether any GDPR or EU AI Act obligations have been triggered.

Comparison with standalone AI tools

Many European SMEs face a choice between Microsoft 365 Copilot and standalone AI tools (Claude, ChatGPT for Business, Perplexity Pro). The governance comparison:

Factor	M365 Copilot	Standalone AI tools
Data access	Full Microsoft 365 tenant (permission-based)	Only what the user manually shares
GDPR complexity	Higher (tenant-wide data exposure risk)	Lower (user-controlled input)
EU data residency	Configurable for EU tenants (Microsoft EU Data Boundary)	Varies by vendor
Integration	Native M365 integration	Manual copy-paste or API
Per-user cost	EUR 28-30/month add-on (as of Q1 2026)	EUR 15-30/month per tool

For a 30-person professional services firm with a well-structured M365 tenant and clear permissions, Copilot is a strong choice for productivity. For a company with a historically messy tenant and limited IT resources, the governance preparation is significant. A standalone AI tool may be the better starting point.

FAQ

Does Microsoft 365 Copilot store our data?

Microsoft uses tenant data to generate Copilot outputs in real time. It does not use your data to train the underlying AI model (per Microsoft's published DPA). Copilot outputs may be stored in the conversation history feature. Data residency is governed by the Microsoft EU Data Boundary product, which provides commitments on where EU customer data is processed and stored.

What is the Microsoft EU Data Boundary and does it cover our organization?

The Microsoft EU Data Boundary is a commitment by Microsoft to process and store data from EU/EEA customers within the EU and EFTA countries. It covers Microsoft 365, Azure, Dynamics 365, and Power Platform. It is not a separate product or purchase. Organizations with EU tenants are automatically subject to these commitments. The DPA provides the contractual basis for GDPR compliance.

We already have Microsoft 365. Do we still need a separate GDPR review for Copilot?

Yes. Adding Copilot changes what AI can do with your existing data. Even if your Microsoft 365 deployment was GDPR-compliant before Copilot, the data access implications of adding AI-driven surfacing require a review of permissions, sensitivity labels, and use case policies. This is not a new GDPR compliance project from scratch; it is an extension of existing governance.

How do we handle Copilot in a hybrid team with contractors and employees?

Contractors typically have guest access in Microsoft 365 tenants, which gives them limited permissions. Copilot licenses can be assigned selectively. The governance decision is: should contractors have Copilot access, and if so, to which data? Guest access management needs to be reviewed as part of the data access review.

AI Governance for Cascais Scale-Ups: Policy Before Growth

Dr Hernani Costa — Mon, 31 Aug 2026 06:57:39 +0000

When your engineering team scales past 25 people, AI tool adoption stops being a founder decision and becomes a compliance liability. For Cascais tech startups and scale-ups selling into Europe, that liability directly impacts your ability to raise capital, pass vendor due diligence, and maintain GDPR compliance.

TL;DR: AI consulting for Cascais tech startups and scale-ups. Strategy, governance, and AI adoption for product teams and founders on the Estoril Coast.

Cascais has attracted a distinct cluster of tech startups and scale-ups drawn by proximity to Lisbon, quality of life, and a growing international tech community around the Estoril Coast. These businesses operate differently from the manufacturing or financial services firms that dominate other Portuguese cities. They are building software products, running engineering teams, and navigating investor expectations while also dealing with the same EU regulatory environment that affects every company operating in the European market.

AI adoption at a Cascais tech startup is a product and engineering decision, not just an operations decision. It affects what the product can do, how the engineering team works, and what the company can credibly claim to investors. This page explains what AI consulting looks like for tech companies in this environment and where a fractional CTO adds the most value.

The Cascais tech profile

The tech companies that have established operations in Cascais range from early-stage SaaS startups to established scale-ups with 50-150 employees. Several patterns are consistent across the cluster:

International founding teams, often with prior experience in London, Berlin, or Amsterdam
Products sold to B2B customers across Europe, which means GDPR compliance is a baseline requirement
Engineering teams that are already using AI coding tools (GitHub Copilot, Claude Code) but without a formal adoption policy
Pressure from investors or board members to articulate an AI strategy that is credible, not aspirational

AI consulting for this profile is different from AI consulting for a traditional SME. The team already has technical fluency. The gap is governance, strategy, and the ability to evaluate AI vendor claims critically.

The three AI questions Cascais tech founders ask

"How do we make our product AI-enabled without building everything from scratch?"

Most tech startups do not need to train their own AI models. They need to integrate capable AI APIs (Claude API, OpenAI API, Google Gemini API) into their product and build the product layer on top. The consulting work involves: selecting the right API for the use case, designing the integration architecture, defining what data the AI sees and does not see, and documenting the governance layer for GDPR and EU AI Act purposes.

A 20-person SaaS company building a customer success platform, for example, might integrate an AI API to generate automated meeting summaries and action item lists. The product layer (the UX, the workflow integration, the CRM sync) is their IP. The AI capability is sourced from an API.

"Our engineers are using Claude Code and GitHub Copilot. What policy do we need?"

This is the most common question from tech companies past the early stage. The answer involves four elements: a permitted tools list, a data handling policy (what can be passed to external AI APIs), a code review requirement for AI-generated code, and an inventory of which parts of the codebase should not be shared with external tools (proprietary algorithms, customer PII, authentication logic).

A fractional CTO translates this into a one-page policy that the engineering team actually follows, rather than a lengthy compliance document that gets filed and ignored.

"Our investors want an AI strategy. What does that actually mean?"

Investors in 2026 are asking two distinct questions when they ask about AI strategy. First, how is AI integrated into the product in a way that creates a defensible advantage? Second, how is the company managing the regulatory and reputational risk of AI use?

The consulting work on the strategy question involves mapping the product's AI integrations, identifying where AI creates genuine user value vs where it is decorative, and articulating the governance approach in terms investors can assess.

What a fractional CTO engagement covers

A fractional CTO engagement for a Cascais tech startup typically runs 2-4 days per month and covers:

AI product architecture review: is the current or planned AI integration designed for performance, cost efficiency, and compliance?
Vendor due diligence: which AI APIs or platforms are appropriate for the data types the product handles? A health tech startup handles different data than a logistics SaaS, and the vendor requirements are different.
Engineering team AI policy: creating the policy that defines how engineers use AI coding tools, what data handling rules apply, and what the review requirements are.
Investor and board communication: preparing the AI strategy narrative for fundraising or board reporting.
EU AI Act assessment: determining whether the product's AI features trigger any obligations under the EU AI Act and, if so, what conformity assessment steps are required.

EU regulatory considerations for Cascais tech companies

Tech companies building AI-enabled products sold in the EU have direct obligations under the EU AI Act as providers of AI systems. The key questions:

Is the AI feature integrated into a general-purpose product (typically minimal-risk) or does it make consequential decisions affecting individuals (potentially high-risk)?
Does the product process special categories of personal data (health, biometric, financial)? If so, the GDPR baseline requirements are stricter.
Is the product sold to regulated customers (banks, healthcare providers, insurers)? Those customers will conduct their own AI due diligence and expect vendors to have their own governance in order.

For most SaaS products in the Cascais tech cluster (project management, CRM, analytics, developer tools), the EU AI Act obligations are manageable: maintain technical documentation, ensure transparency to users when they interact with AI, and have a process for handling AI-related complaints.

FAQ

Does Cascais have specific AI resources for tech startups?

The Cascais municipality and the surrounding Estoril Coast area have general startup support infrastructure (startup incubators, networking events), but there are no AI-specific resources comparable to what is available in Lisbon through Startup Portugal or Nova SBE. Most Cascais-based tech startups access AI resources through Lisbon networks or through European programmes (EIC, Horizon Europe).

How does AI adoption differ between a 10-person startup and a 50-person scale-up?

At 10 people, the AI adoption decision is typically made by the founders and implemented immediately. The governance concern is minimal because the team is small and the founder is close to the code. At 50 people, the team has enough autonomous decision-making that a policy is genuinely necessary. Engineers are making independent decisions about which AI tools to use, what data to pass to external APIs, and what AI-generated code to commit. A fractional CTO engagement makes the most sense at the 25-50+ person stage.

Are there Portuguese funding programmes that cover AI consulting costs?

Yes. Portugal 2030 and the PRR (Recovery and Resilience Plan) include digitalization instruments that can cover AI strategy and implementation costs for qualifying SMEs. The IAPMEI and COMPETE 2030 programmes are the main access points. Eligibility depends on company size, sector, and project type. A Portuguese accountant or business advisor can assess eligibility quickly.

How long does a typical AI strategy engagement take?

An initial AI strategy assessment (understanding current state, identifying priority use cases, assessing regulatory obligations) typically takes 2-4 weeks. Building on that with implementation support (policy documents, vendor evaluation, architecture review) extends the engagement to 2-4 months. Ongoing fractional CTO support continues as long as the company needs senior technical guidance.

Manufacturing Margin Erosion: Why Braga SMEs Need AI Governance First

Dr Hernani Costa — Sun, 30 Aug 2026 06:57:41 +0000

The hidden cost of unplanned AI adoption: operational disruption, compliance risk, and wasted pilot budgets.

Braga's manufacturing sector is one of the most productive in northern Portugal. The region's concentration of automotive components, electronics assembly, and textile production creates a specific type of AI adoption challenge: operations that run on thin margins, precise tolerances, and supplier relationships built over decades. The question is not whether AI applies to these businesses. The question is where it applies first, and what governance is needed to roll it out without disrupting what already works.

This page explains what AI adoption looks like for manufacturing SMEs in the Minho region, what the first productive use cases are, and how a fractional CTO or AI consultant supports that process without requiring a full-time technical hire.

The Braga manufacturing context

Braga hosts a cluster of manufacturing businesses that supply the automotive and electronics sectors across Europe. Many are Tier 2 or Tier 3 suppliers: they produce components to precise specifications and deliver on schedules determined by their customers. Their operations are disciplined, documentation-heavy, and ISO-certified.

This context shapes how AI gets introduced. A 40-person components manufacturer in Braga cannot run a six-month AI transformation programme. They need to identify the two or three processes where AI reduces cost or error rate, pilot it, and integrate it into existing quality management systems.

The businesses that get this right typically start with one of three areas: quality control documentation, supplier communication, or production scheduling analysis.

Quality control documentation

Manufacturing SMEs generate significant volumes of quality documentation: inspection reports, non-conformance records, corrective action forms, and customer audit responses. Much of this is written in standard formats but requires careful language and traceability.

AI tools help in two ways. First, drafting: an operations manager describes a non-conformance event verbally, and the AI drafts the NCR (non-conformance report) in the required format, including the relevant process reference and the corrective action code. Second, translation: Braga manufacturers working with German, French, and Dutch customers often need documentation in multiple languages. AI translation with human review is significantly faster than manual translation.

The governance requirement is simple: every AI-assisted document must be reviewed and signed off by the responsible quality manager before it leaves the facility. The AI is a drafting tool, not an approval authority.

Supplier and customer communication

Manufacturing SMEs in Braga operate in multilingual supply chains. A supplier quality issue with a German Tier 1 requires communication in German. A delivery delay affecting a Dutch customer requires an explanation in Dutch or English. A regulatory update from a French certification body arrives in French.

AI tools with good multilingual capability reduce the friction of these communications. A production manager can describe the issue in Portuguese, review an AI-drafted response in the customer's language, and send it after review. This is not automation: it is an AI-assisted first draft.

The same applies inbound. AI can summarize incoming documentation (supplier data sheets, customer change orders, certification reports) in the production manager's preferred language and flag the three most important action items.

Production scheduling analysis

Scheduling in a contract manufacturing environment is a coordination problem. Customer orders come with varying lead times, material availability changes daily, and machine capacity has hard limits. Most Braga manufacturers manage this with a combination of ERP data and spreadsheets.

AI can help by identifying scheduling conflicts earlier, flagging orders where the lead time is tight relative to typical cycle times, and surfacing patterns in late deliveries (which material, which supplier, which machine centre). This is not AI replacing the scheduler. It is AI giving the scheduler better information before decisions are made.

The integration step is the bottleneck. AI scheduling analysis tools need access to ERP data. Connecting to SAP, Primavera, or PHC (common ERP systems in Portuguese manufacturing) requires an integration project, usually involving the ERP vendor or an integration partner.

What a fractional CTO does for Braga manufacturers

A fractional CTO engagement for a manufacturing SME in Braga typically runs two to four days per month and covers:

Use case prioritization: which AI applications have the shortest path to a measurable outcome, given the existing systems and team capability?
Vendor assessment: there are many AI tools marketed to manufacturing businesses. Which ones have EU data residency, GDPR-compatible data processing agreements, and technical integration paths with the ERP systems the manufacturer already uses?
Pilot design: defining success criteria before a pilot starts, so the decision to expand or stop is based on data rather than impressions.
Governance setup: documenting how AI tools are used, what the human review steps are, and how the outputs are incorporated into ISO quality systems.

The engagement model works for growing companies with 20 to 60 employees that need senior technical guidance but do not have the budget or the volume of technical decisions to justify a full-time CTO.

EU AI Act for Braga manufacturers

Most manufacturing AI use cases (quality documentation drafting, communication assistance, scheduling analysis) are not high-risk under the EU AI Act. They do not affect health, safety, fundamental rights, or consequential individual decisions.

Two exceptions are worth noting:

AI used in safety-critical process control (temperature monitoring, pressure management, safety system decisions) may qualify as high-risk.
AI used in employment decisions (selecting workers for shifts, performance assessment) falls under Annex III and requires conformity assessment.

For standard operational AI, manufacturers need data processing agreements with their AI vendors (GDPR compliance), a record of which tools are in use, and a basic internal policy covering appropriate use and review requirements.

FAQ

Do Braga manufacturers need AI expertise on staff to adopt these tools?

Not at the start. The initial use cases (documentation drafting, communication assistance) require staff who can review and edit AI outputs, not staff who can train or configure AI models. Operations managers and quality engineers can use these tools with brief onboarding. Technical expertise becomes more important when integrating AI with ERP systems or production data.

What does a typical pilot cost for a 30-person manufacturing SME?

A documentation-drafting pilot using a commercial AI tool (Claude, GPT-4, or an industry-specific tool) typically costs EUR 100-300 per month in tool subscriptions, plus the time of the quality manager who reviews outputs. An ERP integration project is more expensive, typically EUR 5,000-20,000 depending on the ERP system and the complexity of the integration.

Are there Portuguese AI consulting firms that specialize in manufacturing?

Yes, though the market is relatively small. Industry associations such as COTEC Portugal and CIP (Confederation of Portuguese Industry) provide resources and occasionally run subsidized AI adoption programmes for manufacturing SMEs. EU funding through Portugal 2030 (successor to PT2020) includes instruments for SME digitalization, some of which cover AI adoption costs.

How does AI consulting differ from the standard digitalization consulting most Braga manufacturers have already done?

Digitalization consulting focused on implementing ERP systems, MES (manufacturing execution systems), and digital quality management. AI consulting starts from those systems and asks: what can we do better with the data those systems generate? The two disciplines are complementary, and the best starting point for AI adoption is usually an existing ERP or quality system with clean, structured data.

Healthcare AI Incidents: The EU AI Act Reporting Playbook

Dr Hernani Costa — Sat, 29 Aug 2026 06:57:44 +0000

When an AI diagnostic tool produces a wrong output that influences a clinical decision, you face three overlapping regulatory frameworks—not just one IT incident ticket. This is where most European healthcare providers fail.

Healthcare AI incidents do not look like IT outages. A software system goes down: you restore it. An AI system produces a wrong output that influences a clinical decision: you need to know what happened, who was affected, what decisions were made based on that output, and what you are legally required to report.

European healthcare providers using AI are now operating under two overlapping frameworks: the EU AI Act (in force since August 2024, with high-risk requirements applying from August 2026) and the Medical Device Regulation for any AI classified as a medical device. This playbook translates those frameworks into a concrete incident response process for clinical directors, compliance officers, and operations managers at small and mid-sized healthcare organizations.

What counts as an AI incident in healthcare

The EU AI Act defines a "serious incident" for high-risk AI systems as one that leads to, or could lead to:

Death or serious irreversible deterioration of health
Serious injury
Damage to property or the environment

For healthcare AI, this is a broad definition. An AI-assisted triage tool that systematically underweights a symptom pattern. A diagnostic support system that flags incorrect risk scores for a patient population. A scheduling algorithm that delays high-priority cases. Any of these could qualify.

Below the serious incident threshold, healthcare AI systems generate anomalies: outputs that are unexpected, inconsistent with the clinical record, or flagged by clinical staff as incorrect. These are not necessarily reportable, but they need to be logged and investigated.

The three-layer regulatory stack for healthcare AI

Healthcare providers in Europe face three layers of AI governance:

Layer 1: GDPR applies to any AI system that processes personal health data. An incident involving personal data (including a data breach caused by an AI system, or an AI output that reveals health data about a person without authorization) triggers GDPR reporting obligations: notification to the supervisory authority within 72 hours if there is a risk to individuals, and notification to affected individuals where the risk is high.

Layer 2: EU AI Act applies to high-risk AI systems (Annex III, healthcare category). Providers deploying these systems must log, monitor, and report serious incidents to the national market surveillance authority. The EU AI Act also requires maintaining logs sufficient to reconstruct the circumstances of an incident.

Layer 3: MDR (Medical Device Regulation 2017/745) applies to AI systems classified as medical devices (software as a medical device, SaMD). MDR requires reporting serious incidents and field safety corrective actions to competent authorities, with specific timelines.

Not all healthcare AI triggers all three layers. A scheduling tool that does not process clinical data may only trigger GDPR. A diagnostic support tool classified as a medical device triggers all three.

The incident response process

Step 1: Detection and containment (0-4 hours)

When an anomaly or incident is identified:

Document the output: save the exact AI output that was flagged, including the timestamp, user ID (if applicable), and the patient encounter or case reference (without unnecessary PII in the incident log).
Assess the blast radius: how many patient cases or clinical decisions were affected by this output pattern? Is this a single-case anomaly or a systematic issue?
Pause or shadow-mode the system if a systematic issue is suspected. Do not wait for root cause analysis to contain a system producing potentially harmful outputs.
Notify the clinical governance lead and the data protection officer (DPO) within 4 hours of detection.

The DPO makes the initial call on whether this triggers a GDPR notification obligation.

Step 2: Assessment and reporting (4-72 hours)

Clinical assessment: the clinical governance lead (or clinical director) assesses whether any patient care decisions were affected and whether any harm occurred or could have occurred. This assessment goes into the incident record.

Technical assessment: the AI system vendor (or internal technical team) identifies the root cause. For commercial AI tools, the vendor has their own reporting obligations under the EU AI Act. They must notify the national authority. The healthcare provider has independent obligations regardless of what the vendor does.

GDPR decision: if personal health data was processed incorrectly, shared without authorization, or if the incident constitutes a personal data breach, the DPO notifies the supervisory authority within 72 hours. In the Netherlands this is the Autoriteit Persoonsgegevens; in Germany, the state-level data protection authority; in France, the CNIL.

EU AI Act decision: for high-risk AI systems, the provider notifies the national market surveillance authority when a serious incident has occurred or when a malfunction of the AI system is discovered that could lead to a serious incident.

Step 3: Root cause and corrective action (72 hours - 30 days)

The root cause analysis answers three questions:

What was the failure mode? (Model drift, incorrect training data, incorrect integration, user error, infrastructure failure)
What governance controls failed to catch it before it reached a patient-affecting outcome?
What change is required to prevent recurrence?

Corrective actions typically fall into one of three categories:

Technical: retraining, recalibration, integration fix, or vendor patch
Operational: process change (requiring a second clinical review for AI outputs above a certain risk threshold), staff training, or workflow adjustment
Procurement: if the vendor's system has a fundamental safety problem, procurement review and possible replacement

Step 4: Documentation and regulatory closure

Every incident requires a closed incident record containing:

Date, time, and source of detection
Clinical assessment (was patient harm caused, possible, or ruled out)
Regulatory notifications made and dates
Root cause summary
Corrective actions taken
Sign-off from the clinical governance lead and DPO

This record is retained for the period required by MDR (minimum 10 years for most medical devices) and made available to regulatory authorities on request.

Roles and responsibilities

Role	Incident responsibility
Clinical governance lead / clinical director	Owns the clinical impact assessment and corrective action decision
Data protection officer (DPO)	Owns GDPR assessment and supervisory authority notification
IT / technical lead	Owns the technical root cause investigation
Operations manager	Coordinates the response timeline and documentation
Vendor contact	Provides technical logs and root cause support; handles their own regulatory notifications

For a 15-person clinic or a small healthcare technology company with 30 employees, these roles may overlap. The DPO may be external (shared DPO service). The clinical governance lead may also be the clinical director. The important thing is that each responsibility has a named person assigned before an incident happens.

Minimum viable incident response kit

A small healthcare provider can be ready for AI incidents with four documents:

AI system inventory: which AI systems are in use, their risk classification (high-risk/limited-risk/minimal-risk under EU AI Act), and whether they are classified as medical devices.
Incident log template: a structured form capturing the fields listed in Step 4 above.
Regulatory contact list: the national supervisory authority (GDPR), the national market surveillance authority (EU AI Act), and any notified body contacts for MDR-classified devices.
Escalation contact list: names and contact details for the clinical governance lead, DPO, technical lead, and relevant vendor contacts.

This is the minimum. Healthcare organizations in higher-risk AI use cases (diagnostic AI, patient monitoring, surgical assistance) should have a full incident response procedure documented and tested.

FAQ

When must a healthcare provider notify under the EU AI Act vs GDPR?

GDPR notification is triggered when a personal data breach occurs (within 72 hours to the supervisory authority). EU AI Act notification is triggered when a serious incident with a high-risk AI system occurs. These can overlap: an AI system producing a data breach AND a clinical incident requires both notifications. They are independent obligations with different recipients.

Does this apply to AI tools we use for administrative purposes?

Administrative AI (scheduling, billing, HR screening) is generally not classified as high-risk under the EU AI Act unless it processes health data in a way that affects patient care. GDPR still applies to any administrative tool processing employee or patient personal data. Check the EU AI Act Annex III and consult your DPO for a definitive classification.

Our AI tool vendor says they handle regulatory reporting. Are we still responsible?

The EU AI Act creates parallel obligations. The vendor (as the provider of the AI system) has their own notification obligations. The healthcare organization (as the deployer) has independent obligations. You cannot delegate your reporting obligation to the vendor. Both parties must report independently when their obligations are triggered.

How does this interact with clinical governance processes we already have?

AI incidents should be integrated into existing clinical governance processes, not run in parallel. If your organization has a clinical incident reporting system (such as a Datix or equivalent), AI incidents should be logged there, with an additional AI-specific module for the technical and regulatory fields. This avoids creating a separate silo of AI incidents invisible to the clinical governance function.

Claude Routines: The $50k Consistency Tax for SME Teams

Dr Hernani Costa — Fri, 28 Aug 2026 06:57:39 +0000

Inconsistent AI outputs are killing SME productivity. When your 25-person team each prompts Claude differently, you're not scaling intelligence—you're scaling chaos. Claude Routines solve this by encoding company standards into reusable instruction templates, turning AI from a personal tool into a team workflow component.

What Claude Routines are

Claude Routines are saved, reusable instruction sets that attach to a Claude session or project. Instead of re-explaining context at the start of every conversation, a routine stores that context and applies it automatically.

A routine might contain:

A persona or role definition ("You are an EU AI Act compliance reviewer")
A set of standing constraints ("Never suggest solutions that require cloud storage in non-EU jurisdictions")
A workflow template ("When I share a document, first summarize it in 3 bullets, then flag any GDPR risks, then suggest three actions")
A reference set ("Use these internal style guidelines when generating copy")

The practical effect: a team member can start a Claude session and the routine activates the full working context without any additional setup.

Why this matters for operations leaders at growing companies

The friction in AI tool adoption at small and mid-sized companies is not primarily the tool itself. It is the inconsistency. A marketing manager asks Claude to review copy. A different marketing manager asks the same question next week and gets a different framing because the context was different.

Claude Routines address this through workflow automation design. A company can define a standard routine for each use case, distribute it to the relevant team members, and get consistent outputs that reflect company standards, not individual prompting skill.

For a 25-person operations team, this is significant. The difference between "everyone prompts however they want" and "everyone uses the approved routine" is the difference between AI as a personal productivity tool and AI as a team workflow component. This is operational AI implementation at scale.

What routines are not

Claude Routines are not automation. They do not run on a schedule or trigger on external events. They are instruction templates, not pipelines.

Operators who want fully automated workflows (where Claude processes inputs without human initiation) should look at Claude Managed Agents or the Claude API with scheduled triggers. Routines are for human-initiated sessions that need consistent framing.

Three practical use cases for SME teams

1. Procurement review: a routine for reviewing supplier contracts might include: "Read the contract, flag clauses that conflict with GDPR data processing requirements, identify non-standard payment terms, and summarize the three highest-risk clauses in plain language." Every procurement manager uses the same starting point.

2. Customer communication drafting: a routine that sets tone, brand voice, and required disclaimers for customer emails. Customer service staff start a session, paste the customer's message, and get a draft that already reflects company standards.

3. Weekly reporting: a routine that takes a data export and produces a consistent report format. The finance manager pastes the CSV, the routine formats the summary table, highlights variance from the previous week, and flags any items that need approval.

What technical teams should know about implementation

Claude Routines are set up through the Claude interface (claude.ai) for teams with business or team subscriptions. They are not currently available through the Claude API in the same way (the API approach uses system prompts, which accomplish the same function but require developer configuration).

For teams using Claude Code: CLAUDE.md files serve the same function at the project level. A well-written CLAUDE.md is a routine for the engineering context.

Key implementation considerations:

Version control: routines should be documented in a shared location (Notion, Confluence, or a shared document) so they can be updated centrally when company standards change.
Access control: decide who can create or modify routines. In most teams, this is a small number of people (one per function or one per team lead).
Audit trail: when a routine produces an output that is acted upon, keep a record of which routine version was used. This matters for compliance contexts under the EU AI Act.

EU AI Act relevance

The EU AI Act does not specifically regulate routines, but the governance principles apply. If a routine is used to make or support a consequential decision (a hiring screen, a credit assessment, a patient triage step), the organization is responsible for the accuracy and fairness of the outputs, even if the instruction template was the source of the problem.

For most SME use cases (drafting, summarizing, reviewing internal documents), routines fall well below the high-risk threshold. Teams should apply common sense: the more consequential the output, the more oversight the routine needs. This is where AI governance and risk advisory becomes essential for EU businesses scaling AI workflows.

FAQ

Are Claude Routines available on all Claude plans?

Claude Routines are available on Claude Team and Enterprise plans. Individual Pro plans have limited routine functionality. Check Anthropic's current pricing page for the latest feature availability.

Can routines access external data or systems?

Not directly. Routines are instruction sets, not data connectors. To give Claude access to external data, teams use MCP (Model Context Protocol) integrations or paste data into the session. Routines can include instructions for how to handle data when it is pasted, but they do not fetch data automatically.

How are routines different from Claude Projects?

Claude Projects store conversation history and can attach files. Routines store instruction sets. They complement each other: a Project might contain the conversation history for a particular client, while a Routine defines how to work on that client's materials. Both are available on Team and Enterprise plans.

Can Claude Routines be shared across a team?

Yes. On Team plans, routines can be shared with team members. On Enterprise plans, administrators can set default routines for the organization.

Codebase Debt: Multi-File Refactoring at Scale

Dr Hernani Costa — Thu, 27 Aug 2026 06:57:38 +0000

Technical debt compounds exponentially. When your codebase grows from 5,000 to 50,000 lines, yesterday's pragmatic shortcuts become tomorrow's operational liabilities—and manual refactoring across hundreds of files becomes a bottleneck that delays feature delivery.

A growing codebase accumulates decisions made at different times by different people. Functions that were fine at 5,000 lines become liabilities at 50,000. The names made sense to the person who wrote them. The module boundaries made sense for the architecture that existed at the time. Refactoring is the work of bringing the code back into alignment with how the system actually operates today.

The problem is that refactoring across multiple files is difficult to hand off to traditional autocomplete tools. Claude Code handles multi-file refactoring differently: it reads the full dependency graph before suggesting changes, tracks what it has modified, and can execute sequences of edits across a codebase in a single session.

This guide explains how engineering teams at mid-sized companies are using Claude Code for large-scale refactoring, what governance checkpoints to build in, and what to watch for when things go wrong.

What makes multi-file refactoring different from single-file work

Single-file changes are relatively safe. The blast radius is contained. A reviewer can read the diff and understand what changed.

Multi-file refactoring carries more risk:

A rename that propagates incorrectly through import statements breaks the build
A function signature change that is updated in 11 of 12 call sites introduces a silent bug in the 12th
Module extraction that changes the import structure can trigger circular dependency errors

Claude Code addresses these risks by reading all relevant files before making any changes. When asked to rename a function, it first searches for all call sites, then makes the changes in sequence. This is the same process a senior engineer follows, but executed consistently across hundreds of files.

The four most common refactoring patterns

1. Function extraction from monolith files: files that grew beyond 1,000 lines typically contain logic that belongs in separate modules. Claude Code identifies clusters of related functions and proposes extraction paths, including the new file names, import adjustments, and any circular dependency risks.

2. Rename with full propagation: renaming a class, function, or variable across a codebase requires finding every usage, including string references in tests and documentation. Claude Code searches across all files in the project scope and applies the rename with consistent casing conventions.

3. Signature harmonization: when a function's interface has drifted from its callers over time, the fix requires updating both the definition and every call site. Claude Code reads the definition, maps all call sites, and applies changes to both in a single session.

4. Dead code identification: Claude Code can scan a codebase for functions, classes, and imports that are defined but never called from within the project scope. It produces a report of candidates for removal and asks for confirmation before deleting anything.

A practical refactoring session

Here is how a 30-minute refactoring session typically runs for an engineering team using Claude Code:

Start with scope definition: tell Claude Code which directory to work in and what the goal is. "Extract all database query functions from src/app/models.py into a new file src/db/queries.py, update all imports, and verify no circular dependencies."

Review the proposed change list: Claude Code lists every file it plans to modify before making any changes. A team lead reviews this list. If the scope is larger than expected, the session is narrowed before execution.

Checkpoint after each logical step: Claude Code works step by step. After each step (extraction, import updates, circular dependency check), a developer runs the test suite. If tests pass, the next step proceeds. If tests fail, the session is paused and the issue investigated before continuing.

Commit after each successful step: small commits with clear messages make the refactoring reviewable. A single 200-file diff is nearly impossible to review. Twelve 15-file diffs, each with a clear commit message, are manageable.

Governance checkpoints for engineering teams

A structured refactoring process reduces the risk of introducing regressions. These are the checkpoints that experienced teams use:

Before starting: confirm the test suite is green. Do not start a multi-file refactoring session on a red build.

After each extraction: run the linter and type checker before moving to the next step. Type errors after an extraction step are easier to fix immediately than after 20 more changes.

Before merging: require a second reviewer for any PR that touches more than 10 files. The second reviewer should focus on the files that were not the primary target of the refactoring, where unintended changes are most likely to appear.

Post-merge: run the integration test suite (not just unit tests) after merge. Multi-file refactoring can break integration paths that unit tests do not cover.

Working with Claude Code in a team environment

Claude Code is a per-seat subscription tool. For refactoring sessions that affect shared code, the team needs a clear ownership model:

Refactoring sessions should be run by one engineer at a time. Two engineers running Claude Code simultaneously on the same codebase will create conflicting changes.
The engineer running the session is responsible for reviewing every change before committing. Claude Code is a fast, capable assistant. The review step is the engineer's responsibility.
Large refactoring tasks should be split across multiple sessions, each with a defined scope. A session that touches 50 files is significantly harder to review than one that touches 15.

For 20-person engineering teams and smaller, the typical pattern is one designated refactoring session per sprint, planned in advance, with the scope reviewed by the tech lead before the session starts.

What to do when Claude Code makes a wrong assumption

Multi-file refactoring sessions occasionally produce unexpected results. The most common issues:

Import path confusion: Claude Code may assume a module path based on the directory structure that conflicts with a custom package configuration. Fix: add the project's package configuration file (setup.py, pyproject.toml, or package.json) to the CLAUDE.md context so Claude Code reads it before starting.

Test file missed: if tests are in an unexpected location, call sites in test files may not be updated. Fix: include the test directory explicitly in the scope definition at the start of the session.

Generated code conflicts: if the codebase contains auto-generated files (from an ORM, protobuf, or OpenAPI spec), Claude Code may modify them. Fix: add a note in CLAUDE.md identifying which files are auto-generated and should not be modified by hand.

FAQ

Can Claude Code refactor across front-end and back-end code in the same project?

Yes. Claude Code is language-agnostic and can read TypeScript, Python, Go, and other languages in the same session. Cross-language refactoring (for example, renaming an API endpoint that is referenced in both the back-end route definitions and the front-end API client) is supported, though it requires care when the naming conventions differ between the two.

How does Claude Code handle version control during refactoring?

Claude Code does not manage git commits. It writes changes to files. The engineer commits using their normal git workflow. The recommended practice is to commit after each logical step, as described in the governance checkpoints above.

What is the risk of data loss during a refactoring session?

The risk of file deletion is low. Claude Code asks for confirmation before deleting files. For modification risks, git provides recovery via git diff and git stash. Teams should ensure they are not running refactoring sessions with uncommitted changes in the working directory.

Does this work for legacy codebases without test coverage?

Claude Code can refactor untested code, but the risk is significantly higher. Without tests, the only way to verify correctness is manual review. For teams with legacy codebases and low test coverage, the recommended approach is to write tests for the code being refactored before starting the session.

DEV Community: Dr Hernani Costa

Coimbra Tech Founders: AI Governance Over AI Tools

The Coimbra Founder Profile and Why It Changes the Consulting Approach

Compliance Context: MDR, EU AI Act, and GDPR as a Sales Requirement

AI Use Cases Relevant to Coimbra Tech Companies

What a Structured AI Consulting Engagement Looks Like for a Coimbra Tech Company

Frequently Asked Questions

Is AI consulting relevant to a Coimbra company that already has strong technical AI capability?

How does the EU AI Act affect health-tech spin-offs in Coimbra specifically?

What should a B2B SaaS founder in Coimbra do first?

Copilot Studio Agents: The Governance Layer Before Autonomous Action

TL;DR

What Human-in-the-Loop Actually Means in a Copilot Studio Context

The Four Action Categories and Their Risk Profiles

The Decision Matrix

Configuring HITL in a Power Automate Flow: The Pattern

What the EU AI Act Requires for Autonomous Agents

What Auditors Will Ask For

Frequently Asked Questions

Does every Copilot Studio agent need a HITL approval layer?

Can we use Copilot Studio's built-in confirmation step instead of a Power Automate approval flow?

What happens if no one approves the request before the timeout?

How often should we review which actions are in which category?

Further Reading

AI Procurement Checklist: Healthcare Buyer's $500k Risk Window

Who This Is For

Six Documentation Areas Before Any Signature

1. EU AI Act High-Risk Classification

2. Medical Device Regulation (MDR) Status

3. Data Processing Agreement Requirements

4. Training Data Provenance

5. Clinical Validation Evidence

6. Incident Response Obligations

The 15-Point Vendor Questionnaire

What to Do With the Responses

Frequently Asked Questions

Does this checklist apply to AI tools we build internally, or only to vendor products?

We are a small clinic with limited procurement resources. Do we really need all 15 questions answered?

What if the vendor is a large company with an established European presence? Can we trust their standard compliance documentation?

How does NIS2 interact with these procurement obligations?

Further Reading

Copilot Checkpoints: EU AI Act Compliance Risk in 5 Gates

Why Checkpoints, Not Just Final Review

The Five Checkpoint Areas for Microsoft 365 Copilot

1. Email Drafting: The Send-Gate Review

2. Document Generation: The Source-Trace Gate

3. Teams Meeting Summaries: The Accuracy-and-Action Gate

4. Excel Data Analysis: The Assumption-Disclosure Gate

5. SharePoint Search and Synthesis: The Access-Scope Gate

Building the Log: A Lightweight Format

What This Does Not Cover

Frequently Asked Questions

How many checkpoints do we realistically need to implement at once?

Do checkpoint logs need to be retained for a specific period under EU AI Act rules?

What if our team sees checkpoints as bureaucracy and stops doing them?

Does this apply to Copilot used internally only, or also to Copilot outputs shared with clients?

Further Reading

EU AI Act Enforcement Active: $15M Fine Risk & SME Checklist

EU AI Act Enforcement Is Active: What Q1 2026 Brought and What to Check Now

What Happened in Q1 2026: The Enforcement Landscape

What Article 6 High-Risk Classification Means in Practice

The 10-Point Compliance Checklist for European SMEs

Which SME Use Cases Attracted Early Compliance Attention

What the Fractional CTO or External Adviser Angle Looks Like

Frequently Asked Questions

Does the EU AI Act apply if I only use off-the-shelf AI tools and do not build anything?

What happens if I miss the August 2026 grace period deadline?

How do I know if a system "substantially influences" a decision?

Further Reading

Agentic AI Workflows: EU SME Governance Before Deployment

What "Agentic" Actually Means (Without the Hype)

Which SME Use Cases Are Ready in 2026

What Changes in Your Workflows When You Deploy Agentic AI

What the EU AI Act Requires for Automated Decision Systems

What to Put in Place Before You Deploy

Frequently Asked Questions

Is agentic AI only for large enterprises with big technical teams?

How do I know if my planned use case counts as high-risk under the EU AI Act?

What is the most common mistake SMEs make when deploying agentic AI?

Further Reading