There's a specific feeling in project rooms when someone asks "but what exactly do we need to test?". It's silence. Not the silence of someone thinking, but the silence of someone who doesn't have an answer and expected someone else to have it. The tester looks at the PO. The PO looks at the dev. The dev looks at the requirements document that has three versions and none of them is final.
For years, that silence was the most honest symptom of a broken process. It exposed that nobody had defined what "approved" actually meant.
AI solved that problem. Not by answering the question. By filling the silence.
The Silence That Became a Document
When you paste a specification into Copilot and ask it to "generate acceptance criteria for this flow," the response comes in seconds. Formatted. Numbered. With positive and negative scenarios. With precise technical language.
It looks like a professional deliverable. And sometimes it is.
The problem is when it isn't. When the specification you pasted was ambiguous, incomplete, or simply outdated, AI doesn't warn you. It fills the gaps with assumptions that make sense from the code's perspective, but not from the business's perspective.
AI doesn't tell you what you don't know to ask. It gives you an answer that looks complete enough for you to stop asking.
The tester reads the criteria, thinks they look fine, runs the tests, everything passes. The flow goes to production. And the bug appears not because the code was wrong. But because the criterion that should have caught it never existed.
What AI Cannot Invent
Acceptance criteria have two components. A technical one: what the system does. A business one: what the system needs to do for that specific person, in that context, in that company.
The technical component AI handles well. Given a Power Automate flow, it can identify paths, conditions, and expected exceptions.
The business component isn't in the code. It's in the head of the HR manager who will use that flow every Monday. It's in the behavior of the user who will fill out the form on a mobile phone with a poor connection. It's in the exception that happens once a quarter and that the client considers critical, but that nobody documented.
That knowledge doesn't live in any repository that AI can read.
So when you ask AI to generate criteria without first extracting that knowledge from the right people, it generates what it can. What it has. And it delivers it with the same confidence it shows when what it has is actually enough.
Approved by a System That Doesn't Understand the Process
In Microsoft environments, the problem has an extra layer. Power Automate, Copilot Studio, SharePoint Forms: these are tools that democratized the creation of digital processes. Anyone with an M365 license can build a flow.
And can test that flow with Copilot's help.
What nobody saw coming: when the person who built the flow is the same person who asked AI to generate the test criteria, blind spots multiply. AI learns from what the creator provides. If the creator didn't see an edge case, AI won't see it either.
The result is a closed loop that validates itself. The flow passed the tests. The tests were generated by the same system that generated the flow. Nobody from outside looked at it with the eyes of someone who will actually use it in production.
What to Do Before Asking AI to Write Anything
AI is an excellent tool for documenting criteria that someone already understands. The problem starts when it's used to replace the process of understanding.
Before generating any criteria with Copilot or any other model, some questions need answers in human language, preferably in writing:
- Who will use this process and under what conditions?
- What does "it worked" mean for that person?
- What are the scenarios that cannot fail, even if they rarely happen?
- What should the system not do, even if it technically can?
With those answers, AI becomes genuinely useful. It transforms that understanding into structured criteria, covers variations you didn't think of, and speeds up what used to take hours.
Without those answers, it fills the silence. And silence, as always, has a cost.
The Point
The question isn't whether your team uses AI for QA. It's whether your team knows what it's testing before asking AI to write the test.
If the answer is "more or less," you don't have a tooling problem. You have the same problem as always, only now it's very well documented.
Want to keep this conversation going? The MacarenoNet newsletter brings a read like this every week: no hype, no manual, just what matters.
Sources
- Batch testing for prompts (preview) - Microsoft Learn
- Using Microsoft Copilot for Microsoft 365 to Generate Manual Test Cases from User Stories - NashTech Blog
- Microsoft Copilot + Power Automate: Business Use Cases in 2026 - The Sunflower Lab