Team policy, honest measurement and regulation
A short, clear team policy turns good intentions into everyday habits. Teams should measure AI's benefit honestly, including the time spent checking output and the defects it introduces, and stay aware that regulation of AI is growing and differs by country and industry.
Why a team policy
Organisation-wide AI policies are often broad. A team working on core banking batch needs to know concretely what is allowed on Tuesday morning. A good AI usage policy for a mainframe team is short enough to remember and specific enough to follow.
| Policy area | Example content |
|---|---|
| Tools | Which assistants are approved, for which data classes, and how to request new ones |
| Data | No production data, secrets or client-restricted code; how to sanitise logs |
| Use cases | Encouraged: explanation, documentation drafts, test case ideas. Needs extra care: production code changes, JCL for production jobs |
| Verification | Minimum evidence: compile, tests, output comparison for logic changes, independent review |
| Recording | How AI assistance is noted in commits or change records |
| Learning | Juniors must be able to explain submitted code; pairing on AI-assisted work |
| Incidents | What to do if sensitive data was shared with a tool by mistake |
Measuring benefit honestly
Claims about AI productivity range widely. The only numbers that matter for your team are your own, measured fairly. Count both sides:
- Compare like with like: similar tasks with and without the tool, not hand-picked successes.
- Measure outcomes (defects, incidents, cycle time), not just lines of code or prompts used.
- Watch for hidden costs, such as reviewers spending longer on large AI-generated changes.
- Re-measure over time; early enthusiasm and novelty both distort results.
It is a perfectly good outcome to find AI helps a lot with explanation and documentation, a little with tests, and not at all — or negatively — with some production changes. Honest measurement lets the team use it where it pays off.
Regulatory awareness
You do not need to be a lawyer, but you should know that AI use sits inside a regulated environment. At a concept level:
- Data protection laws (for example GDPR in the EU and UK) apply to personal data whether it is processed by people, programs or AI tools.
- AI-specific regulation is emerging; the EU AI Act is one example, with obligations that depend on how risky a use is. Requirements and timelines vary by jurisdiction.
- Financial-sector rules on operational resilience, outsourcing and model risk can apply to AI tools and their providers.
- Industry standards such as PCI DSS for card data still apply to anything that touches that data.
What applies depends on your country, industry and how the tool is used. Your compliance and legal teams interpret it; your job is to follow the policy and raise questions when a use case looks new.
1. Use only assistants on the approved list, via company accounts. 2. Never include production data, secrets or client-restricted code. 3. Logic changes need tests and output comparison before review. 4. Note AI assistance in the commit message. 5. If in doubt, ask. If something leaked, report it the same day.
Common mistakes
Time saved writing is offset by time spent checking. Count both or the numbers will mislead.
Long policies are ignored. Keep the team version short, concrete and part of onboarding.
Unreported leaks cannot be contained. Report immediately; good teams treat it as a process failure to fix.
What you will see at work
- Team leads are asked to report how AI tools are used and what benefit they bring.
- Onboarding checklists increasingly include the AI usage policy alongside security training.
- Compliance teams review new AI use cases, especially those touching customer data.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.