Domain review: responsible AI

Tuesday, August 24 began with the domain Dmitri thought he knew best and had still lost two questions on. Responsible use of GitHub Copilot is worth 15 to 20 parts in 100 of the exam, the second largest share, and its questions are rarely about definitions alone. They describe a developer accepting a suggestion, a team rolling out Copilot or a manager reading metrics, and ask what the responsible step is. Priya organized the session around four questions the domain keeps returning to: what can go wrong with generative AI output, why it goes wrong, how to check it, and who stays accountable.

Principles behind responsible AI

Microsoft and GitHub describe responsible AI with a familiar set of principles: fairness, reliability and safety, privacy and security, inclusiveness, transparency and accountability. The exam does not ask you to recite the list, but it expects you to recognize each principle in a scenario. A suggestion that only works for English user names raises fairness and inclusiveness. A model that is confidently wrong raises reliability. Copilot showing where a suggestion matched public code is transparency. A developer remaining responsible for what is merged is accountability.

At Tidewater the principles had been turned into one page of team guidelines during the summer, kept in the admin repository. Dmitri reread it before the session. It said that people own what they merge, that guidebook prose stays human-written on the lawyer's advice, that agent work is bounded and gets an independent reviewer, that significant AI help is disclosed in the pull request, and that metrics are read at team level and never used to rank people. Each line traces back to a principle, which is a useful way to remember the principles: as rules a real Atlantic Canada publisher actually follows.

Why generative AI gets things wrong

Copilot is built on large language models. A language model predicts likely next tokens from patterns learned in training and from the context it is given. It does not look up facts or run your code before answering. That design explains the limitations the exam lists. A model can hallucinate, producing code that calls functions or options that do not exist, because they look like things that do. It can repeat outdated patterns learned from older code. It can reflect bias in its training data. Its knowledge has a cut-off, so it may not know a library's newest version. And it is limited by context: if the relevant file or rule is not in the context window, the model cannot use it.

These limits are not occasional bugs that a newer model will remove. They come from how the technology works, which is why the exam treats validation as a permanent habit rather than a workaround. Better models and better context reduce errors; they do not make review unnecessary.

Validating output

Every responsible-use question eventually comes back to validation. GitHub's guidance is to treat suggestions the way you would treat code from a colleague you do not know yet: read it, understand it, test it and review it before it reaches production. In practice that means a short checklist. Does it do what was intended? Does every function, option and package it uses actually exist, at the version you have? Does it handle the edge cases, such as empty input, unusual characters and boundaries? Is it secure: no injected queries, no secrets, no unsafe defaults? Do the tests test the right thing, or just pass? Is the licence position clear if it resembles public code?

Copilot can help with its own validation: asking chat to explain a suggestion, to list edge cases or to write tests from the specification are all good practice. What it cannot do is take responsibility. The exam often offers an option such as "accept the suggestion because Copilot was trained on high-quality code" or "skip review because the tests Copilot wrote pass"; those are always wrong, because they hand accountability to the tool.

Operating Copilot responsibly in a team

The domain also covers how organizations use Copilot, not only how individuals do. Responsible operation includes clear guidelines on what Copilot may be used for; training so people understand its limits; settings that support policy, such as content exclusions, the public code filter and controls on preview features; human review on every pull request, including those opened by agents; and transparency with customers or users where AI-generated content affects them. It also includes thinking about people: AI tools change how work is done, and a team that measures Copilot by lines accepted, or ranks individuals by acceptance rate, creates the wrong incentives.

Accessibility is a part of responsible use that candidates often forget. Generated front-end code can omit labels, alt text and keyboard handling. Asking Copilot explicitly for accessible markup, and testing with an accessibility checker or a screen reader, is the responsible step. Similarly, generated text such as error messages should be clear and respectful.

Risks to watch for

Dmitri's two wrong answers on Monday were both about over-reliance. One asked what a team should do when junior developers accepted most suggestions without reading them; he had chosen "turn off Copilot for junior staff", while the better answer was training plus mandatory review. The other asked how to judge whether Copilot was helping; he had chosen acceptance rate, while the better answer combined outcome measures with developer feedback. Both were questions he could answer from Tidewater's own experience in Moncton; he had simply reached for the quick fix.

Ownership and transparency

Who owns code that Copilot suggests? GitHub's position, stated in its terms and documentation, is that it does not claim ownership of suggestions; you are responsible for the code you choose to use, as with code from any other source. The legal question of copyright in AI-generated material is unsettled and varies by country, which is one reason Tidewater kept its guidebook prose human-written. The exam stays at the practical level: you own and are accountable for what you accept, you should check licences where suggestions match public code, and organizations can choose settings that reduce the risk.

Transparency means being open about AI involvement where it matters. Tidewater asked authors to note significant Copilot help in pull request descriptions, so reviewers knew to look harder at generated tests and agent changes. For users of a product, transparency can mean telling them when content or decisions involve AI. The exam may describe a team hiding AI use from reviewers or customers; the responsible answer is disclosure.

Three exam-style scenarios

Responsible-use questions are usually short stories with one sentence that matters. Priya wrote three in the style of the practice assessment and had Dmitri find that sentence before looking at the options.

In the first, a developer asks chat to write a function that checks whether a volunteer is old enough to lead a youth hike, and Copilot produces a neat function that compares the birth year with the current year. The sentence that matters is the one about age: a check based only on years is wrong for anyone whose birthday has not yet come this year. The responsible answer is not "trust the function because it is short" but "test the boundary cases, such as a birthday tomorrow, and correct the logic". The domain is reliability, and the habit is testing against the rule, not against what the code happens to do.

In the second, a team lead notices that Copilot chat answers about the team's internal deployment process are often wrong, and proposes telling developers to stop asking. The sentence that matters is that the process is internal: the model has never seen it unless it is in the context. The better answer is to give Copilot the context it lacks, through custom instructions, a Copilot Space with the deployment notes, or by referencing the right file, and then to keep validating. Banning the question treats a context problem as a model problem.

In the third, a manager wants to show the board that Copilot is working and plans to publish a chart of each developer's acceptance rate. The sentence that matters is "each developer". Ranking individuals by acceptance rate rewards accepting without reading and damages trust, and acceptance is an activity measure, not an outcome. The responsible answer reports team-level outcomes, such as time to merge or defects after release against a baseline, together with what developers say about their work. Tidewater's guidelines say exactly this, and the pilot report to the owners in July used team figures only.

In each case the wrong options were tempting because they were quick: trust it, ban it, chart it. The right options all added a step a careful person would take anyway. That pattern, Priya said, holds for most of the domain: when two answers seem plausible, the responsible one usually keeps a human in the loop, adds context or evidence, or protects people.

A short self-test

Priya finished with five rapid questions, answered aloud. What should you do before accepting a suggestion that calls an unfamiliar function? Check that it exists in the documentation for your version. What makes a prompt more likely to produce inclusive output? Stating the requirement explicitly, such as accepting all Unicode letters in names, and testing with varied data. Who approves a pull request opened by the coding agent? A person with review rights, never the agent itself. What is a hallucination? Plausible but invented output. What is the risk of measuring developers by acceptance rate? It rewards accepting without reading. Dmitri got all five, and moved responsible AI from amber to green on his skill list.