You do not need to understand every model, connector or licence to lead an AI project. You do need to make the team’s decision, risk and evidence visible.
Bluffing is more dangerous than saying “show me how we know”. A manager’s job is to create a process in which technical claims can be challenged without turning the meeting into a performance of expertise.
Start with the work, not the product
Replace “we need an AI agent” with a short operating statement:
When a support request arrives, the team needs a cited draft classification within the existing service process. A person approves any action that changes a customer record.
That sentence identifies the event, output, context and human boundary. It also gives the technical team something concrete to test.
Ask five questions at every gate
1. What exactly is the system allowed to do?
Distinguish reading, drafting, recommending and acting. An agent that writes a suggested reply has a different risk profile from one that sends it or changes a record.
Microsoft warns that data from untrusted sources can manipulate an agent and that sensitive actions need careful human intervention. Its Copilot extensibility security guidance is a useful reference for this boundary.
2. Which identity and permissions does it use?
Ask whether the system acts as the user, an application or a service identity. Request the actual scopes, data sources and connector list.
“It respects permissions” is not enough. You need to know whether the permissions themselves are appropriate and whether the action can reach more than the pilot requires.
3. How will we know it works?
Agree acceptance cases before the demo:
- ordinary input;
- ambiguous input;
- missing data;
- hostile or misleading input;
- connector failure;
- unauthorised request;
- a case requiring human escalation.
Record expected and actual results. A smooth demonstration proves the chosen demonstration worked.
4. What happens when it fails?
Every production proposal needs a stopping rule, manual route, owner, alert and rollback. If the team cannot explain those in plain English, the project is not ready for broader use.
5. What changes for staff and customers?
Map who reviews the output, who gets extra work when confidence is low and who explains a wrong answer. Automation can move work rather than remove it.
Separate the four kinds of statement
Meetings get muddled when these are mixed:
- Evidence: the pilot passed the pre-agreed cases recorded in its test log.
- Inference: performance may improve with cleaner source material.
- Forecast: the team expects fewer manual classifications next quarter.
- Opinion: this is the best use case to fund.
Write the label next to important claims. It makes honest disagreement much easier.
Put governance in the delivery plan
NIST’s voluntary AI Risk Management Framework organises AI risk work around governing, mapping, measuring and managing. You do not need to adopt every artefact to use the logic.
A modest project should still have:
- named business, technical and data owners;
- approved data and prohibited data;
- privacy and security review proportional to consequence;
- a test set and evaluation record;
- change control for prompts, models and tools;
- incident and feedback routes;
- review dates and retirement criteria.
Licensing and product boundaries
AI features, connected data, capacity and administrative controls vary by product, account, licence, region and release status. Ask the team to link current vendor documentation and show the tenant configuration.
For Microsoft Copilot and agents, the current Copilot Control System guidance separates foundational and optimised controls and makes licensing differences explicit.
Guidance checked on 24 August 2026. It does not replace legal, employment, privacy or security advice for a specific organisation.
For practical ways to lead Copilot work without pretending certainty, join the Microsoft Copilot Adopters Space.