AI Applications
Completing a Responsible AI Questionnaire: What Reviewers Actually Look For
A practical walkthrough of the Responsible AI questionnaire most organisations now require before an AI system is built, bought or deployed: what completion means, what each section asks, the four answers that cause nearly all the rework, and how to clear review in one round.
CSEWhy ·
A practical walkthrough of the Responsible AI questionnaire most organisations now require before an AI system is built, bought or deployed: what completion means, what each section asks, the four answers that cause nearly all the rework, and how to clear review in one round.
What "completion" actually means
A Responsible AI questionnaire is a structured self-assessment you fill in before an AI system is built, procured or shipped. It is considered complete when a named reviewer accepts your answers and the system gets assigned a risk tier, not when you click submit. That gap between submitting and being accepted is where most teams lose a fortnight.
The form usually arrives from one of four places. Your own organisation's AI governance board or risk function, because someone logged a new AI use case. An enterprise client's procurement team, as part of vendor due diligence before they let your model near their data. A cloud or model provider, gating access to a restricted capability. Or an institutional ethics committee, if the work sits inside a university or a hospital.
The wording differs. The underlying structure almost never does, because nearly every version traces back to the same two or three sources: the NIST AI Risk Management Framework from January 2023, ISO/IEC 42001 published that December, and Microsoft's Responsible AI Impact Assessment template. Learn the structure once and every variant becomes readable.
The sections, and what the reviewer is really checking
Read the second column before you start typing. Reviewers are not grading your prose. They are looking for whether you can describe the system concretely enough that someone else could audit it later.
| Questionnaire section | What it asks | What the reviewer is checking |
|---|---|---|
| System description | What the system does, what it outputs, where the output goes | Whether a non-technical reader could restate it accurately |
| Intended and unintended use | Approved use cases, and uses explicitly out of scope | That you have written down at least two things the system must not be used for |
| Data | Sources, provenance, consent basis, personal or sensitive attributes | Whether you can name the lawful basis and the retention period, not just the dataset |
| Affected stakeholders | Who is impacted, including people who never touch the interface | That you listed non-users: rejected applicants, flagged employees, third parties |
| Harms and failure modes | What goes wrong, who it hurts, how badly | Severity and reversibility, not a generic mention of bias |
| Fairness evaluation | Groups tested, metrics used, results | Actual numbers across actual subgroups, or an honest admission that none were run |
| Human oversight | Who reviews, who can override, when | A named role with authority and time to intervene |
| Monitoring and fallback | Drift checks, incident route, what happens when it fails | That the fallback is a real process, not "we turn it off" |
The four answers that cause almost all the rework
Out-of-scope use is the one people skip. They describe the approved use case well and leave the restrictions blank. Write the restrictions. If you built a CV screener that ranks candidates for a shortlist, say plainly that it must not be used to auto-reject, and that it is not validated for roles outside the ones you tested.
Data provenance is the second. "Internal data" is not an answer. Name the system of record, the date range, the consent or contract basis, and whether anything personal is in there. If you are in India and the data covers identifiable people, the Digital Personal Data Protection Act 2023 makes this question load-bearing rather than cosmetic.
Affected stakeholders is where most submissions are quietly wrong. Teams list their users. The people who carry the risk are usually elsewhere: the loan applicant who gets scored, the gig worker whose shift allocation changes, the patient whose triage order moves. If your stakeholder list and your user list are identical, you have probably missed the group the questionnaire exists to protect.
Human oversight is the fourth, and it is the one reviewers push back on hardest. "A human reviews all outputs" fails if that human sees 400 cases a shift and has no realistic ability to disagree. State the role, the volume, the override mechanism, and what evidence the reviewer actually sees. Rubber-stamping is a known failure mode and experienced reviewers look for it.
How to get through in one round
Treat it as a documentation exercise you do while building, not a form you fill after. The teams that clear review fastest are the ones who already had the answers written somewhere else.
- Pull the latest version of the questionnaire before you start. These templates get revised quarterly in most large organisations and reviewers notice stale forms.
- Draft with the person who built the pipeline in the room. Product managers guess at data lineage and guess wrong.
- Run a basic subgroup evaluation before submitting, even a rough one. An honest table beats "not applicable".
- Write a one-line answer and a two-line justification for every risk you mark as low. Unjustified low ratings trigger the longest review cycles.
- Attach evidence: evaluation outputs, the data processing agreement, screenshots of the override interface.
- Ask for the risk tier in writing when you get sign-off, and the re-assessment trigger with it.
This is turning into a job skill, not a compliance chore
Three years ago this form landed on a legal team. Now it lands on whoever is shipping the feature, and that person is increasingly an analyst, a product owner or an operations lead with no governance training. The EU AI Act's obligations for high-risk systems take full effect on 2 August 2026, and India's MeitY released its AI Governance Guidelines in November 2025, which means the number of people in Indian companies who will be asked to complete one of these in the next eighteen months is going up sharply.
The skill itself is narrow and learnable. You need to be able to describe an AI system precisely, identify who is exposed to its errors, run a basic fairness check, and design an oversight step that would survive a sceptical question. Most people get there in a few guided attempts on real systems rather than by reading a framework document.
If your team is about to face this across several projects and nobody has done one before, that is the kind of thing worth working through with a mentor on your actual use cases, which is what our AI Masterclass sessions for professionals and corporate teams are built around. Tell us the system you are assessing and we will tell you whether a short workshop or a longer implementation track is the right fit.
One last thing. A completed questionnaire is a dated snapshot. Change the model, the data source or the decision it feeds, and the completion lapses. Build the re-assessment trigger into your release process now, because finding out at audit that your sign-off described a system you stopped running in March is a worse conversation than filling the form again.
FAQs
1. How long does a Responsible AI questionnaire take to complete?
Two to four hours of drafting for a straightforward internal system, assuming you already know the data sources and have evaluation results. Review and sign-off typically adds one to three weeks, longer if the system touches personal data or affects decisions about people.
2. Do I need to redo the questionnaire if I change the model?
Usually yes. Most governance policies treat a change of model, training data, or the decision the output feeds as a trigger for re-assessment, while prompt tweaks and UI changes generally do not. Confirm the specific trigger conditions with your reviewer at sign-off so you are not guessing later.
3. Who signs off on a Responsible AI questionnaire?
It varies by organisation, but the typical chain is the system owner submitting, a risk or AI governance reviewer assessing, and a business or legal approver accepting residual risk. For high-risk tiers a second reviewer or an ethics committee is often added.
4. Is a Responsible AI questionnaire the same as a DPIA?
No. A Data Protection Impact Assessment focuses on privacy risk to personal data and is a legal requirement in specific situations, while a Responsible AI questionnaire covers a wider set of concerns including fairness, reliability, transparency and human oversight. Many organisations run both and cross-reference them.
5. Is completing one legally required in India?
There is no standalone Indian law mandating a Responsible AI questionnaire as of early 2026. Obligations arrive indirectly through the Digital Personal Data Protection Act 2023, sector regulators like RBI and SEBI, the MeitY AI Governance Guidelines released in November 2025, and contractual requirements from enterprise clients, especially those exporting to the EU.
6. What if my AI use case is genuinely low risk?
Say so, and justify it in two lines: no personal data, no decision about a person, reversible output, human in the loop. Low-risk systems usually get a lighter review path, but an unjustified low rating is the most common reason a submission gets bounced back.