Applied AI: use it where it helps, and verify what it produces

The core problem: output is probable, not guaranteed

A traditional function returns the same answer for the same input. A language model returns a likely answer. That is useful, and it means the cost of verification moves to the user. Brooks’s point that the hard part of software is its essential complexity applies here too: AI can draft code quickly, but someone still has to decide whether the code is right.

Where to start: low-risk, reversible, checkable

A practitioner’s first question is not “can AI do this?” but “what happens if it is wrong, and how will we know?” Good first uses have three properties: a mistake is cheap, a mistake is visible, and a person or a test can check the result.

• Drafting tests, documentation or boilerplate that a reviewer will read.
• Searching and summarising internal material, with sources shown.
• Suggesting changes in a pull request that still needs human approval.

Checks that belong before anything merges

• Automated tests that fail when behaviour changes, so generated code is held to the same bar as human code.
• Human review of anything touching security, money or personal data.
• Secrets and personal data kept out of prompts and out of generated code.
• A record of which output came from a tool, so problems can be traced.

Designing systems that include a model

When a product calls a model, treat it as an unreliable component. Retrieval-augmented generation, introduced by Patrick Lewis and colleagues in 2020, grounds answers in documents you control. It helps, but it adds its own parts that can fail: how documents are split, how they are ranked, and whether the answer is faithful to the source. Test each part. Measure answers against a fixed set of questions so you can see whether a change made things better or worse.

• Cost and rate limits. Put limits and fallbacks around every call.
• Data privacy. Decide what may leave your boundary before you integrate.
• Observability. Log inputs, outputs and decisions so you can investigate an odd answer.

Follow the published frameworks

You do not have to invent your own risk language. The NIST AI Risk Management Framework and the OWASP list of risks for applications built on language models are public, maintained, and a good starting vocabulary. For evidence on how AI changes delivery performance, read the latest DORA reports directly rather than relying on summaries.

Applied AI & Emerging Tech Integration is 16% of the ATP exam and 18% of the CTP exam, and the largest share (36%) of the specialist AI Practitioner (AIP) exam. See exam facts.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.