David is the VP of Talent Acquisition at a 5,000-person retail and logistics company that hires at high volume, roughly 3,500 hires a year across warehouse, store, and corporate roles, supported by a TA organization of about 40 recruiters. Over two years his teams adopted AI tools opportunistically: a screening assistant here, a chatbot there, a video-assessment platform in one division. No two divisions did it the same way, nobody owned the decisions centrally, and when the legal team asked who had approved the video platform and whether it had been audited for bias, the honest answer was that no one had, because there was no process to approve or audit anything. This capstone project produces the missing layer: a written governance framework you could hand to your own legal partner tomorrow.

What You Are Drafting, and What Makes It Real

A governance framework is the set of structures, principles, and policies that decide how AI gets evaluated, approved, monitored, and retired in your recruiting function, and who is accountable when something goes wrong. It is not a values statement and it is not a slide about responsible AI. It is an operating document with names in it. The deliverable here has six concrete parts: a governance structure with named roles and decision authority, a short set of ethical principles, a policy clause set stating what is required and what is prohibited, an escalation protocol with clocks, an audit cadence carrying a standing bias-audit requirement, and a training curriculum that teaches people the duties the framework assigns them.

The test of a good framework is not how impressive it reads. It is whether it has teeth, meaning real authority, real accountability, and real consequences when policy is ignored. Every drafting decision in the sections below is aimed at that single property, and the fastest way to check your own draft is to read each clause and ask what actually happens if someone ignores it tomorrow. If the honest answer is nothing, you have written a preference rather than a policy, and you should either add the consequence or delete the clause.

Part One: Governance Structure, and Who Decides

David designs a structure that is cross-functional by default, because the central failure mode of AI in recruiting is the siloed decision: the tool chosen by recruiting alone that legal or data later has to unwind at far greater cost. He establishes an AI Recruiting Governance Committee with five standing seats, the VP of Talent Acquisition as chair plus one representative each from Legal and Compliance, Data and Privacy, HR, and IT and Security. The committee owns three powers: approving any new AI tool before deployment, reviewing audit results on a fixed cadence, and ordering a tool suspended when a policy is breached. Powers, not opinions, is the operative distinction.

Authority is spelled out in a decision matrix so that no approval ever depends on someone's reading of the org chart. Write yours as a grid rather than as prose, because the grid forces you to notice the cases you have not thought about, and because a recruiter with a question can find their row in seconds.

Each AI tool also gets a named accountable owner, a single person responsible for that tool's documentation, monitoring, and audit. Diffuse accountability is the same as no accountability; one name per tool is what makes the structure real. The last row of the matrix matters more than it looks: if suspension requires convening the full committee, a confirmed problem runs until the next meeting. Giving the chair interim suspension authority, exercised on the record and reviewed at the next session, is what keeps the framework's most consequential power usable on the timescale problems actually appear.

Part Two: Principles Specific Enough to Act On

David drafts four principles, and he writes each as a testable commitment rather than a slogan, because a principle you cannot point to in a decision is decoration. His four: a human makes every final hiring and rejection decision, and no candidate is rejected by a tool alone. Every tool that evaluates candidates is audited for bias before deployment and at least annually thereafter. Candidates are told when AI is used in their assessment and what it evaluates. Any tool whose fairness cannot be explained or audited is not deployed, regardless of its accuracy.

Three to five principles is the right range. Fewer and they are too abstract to decide anything; more and nobody remembers them, which defeats the purpose of having them. The drafting test David applies to each candidate principle is simple: can you name a specific decision it would have changed? "We use AI responsibly" fails that test. "Any tool whose fairness cannot be explained or audited is not deployed, regardless of its accuracy" passes, because it rules out a purchase someone will otherwise want to make on the strength of a demonstration. Each of David's four maps directly to a policy clause and an enforcement step below, which is how principles become governance instead of aspiration.

Part Three: The Policy Clause Set

This is the operative heart of the framework. David writes each policy as a clause with three fixed elements: a role accountable, a stated requirement, and an enforcement consequence. The third element is the one most drafts omit and the one that determines whether the document changes behavior. A representative clause set for a recruiting function, which you should adapt rather than copy, looks like this.

Notice the drafting pattern in the consequence column. Every consequence is something a system or a named person can actually do: suspend, disable, pause, withhold access, decline renewal. None of them is "will be addressed" or "may result in disciplinary action," because those phrases describe an intention rather than a mechanism. When you draft your own set, write the consequence first and the requirement second. If you cannot name a consequence you would genuinely apply, the clause is aspirational and belongs in the principles section instead, where it will at least not corrode the credibility of the clauses around it.

The three-way vocabulary of required, prohibited, and encouraged is worth keeping distinct in your draft. Required and prohibited items carry consequences and are auditable. Encouraged items are genuine guidance with no enforcement attached, and labeling them honestly protects the required ones. A framework that dresses preferences up as mandates trains people to treat all of it as advisory, which is exactly the outcome you are drafting against.

Part Four: The Escalation Protocol

The escalation protocol answers who acts, in what order, on what clock, when a concern is raised. David's protocol runs as a single traceable path. Any employee or candidate can raise a concern to the tool owner or to any committee member, and the multiple entry points are deliberate, because a protocol with one door fails whenever that door is the problem. The tool owner acknowledges within two business days and completes an initial assessment within five. If the concern involves potential bias or legal exposure, it escalates to the full committee, which decides within ten business days whether to suspend the tool, adjust it, or close the issue, and documents the rationale either way. A confirmed adverse-impact finding triggers suspension of the affected use pending correction.

The protocol names timelines on purpose, because a process with no clock is a process that quietly never resolves. Draw yours as a flowchart before you write it as prose: the visual form exposes the dead ends, the steps with no owner, and the branches where a concern can be closed without a finding. Two rules keep the path honest. First, every concern is closed with a written outcome, one of data error, no action with reasons, tool adjusted, or tool suspended, so that "still looking at it" is never a resting state. Second, the person who raised the concern is told what happened. A protocol that consumes concerns without visible response teaches the organization to stop raising them, and that silence will read as compliance right up until it does not.

Part Five: Audit Cadence and the Standing Bias-Audit Requirement

David sets a calendar so monitoring is routine, not reactive. Selection-rate fairness metrics are reviewed monthly by each tool owner against the four-fifths rule. The full committee reviews aggregated audit and fairness results quarterly. Each candidate-evaluating tool receives a full independent bias audit annually, and any new tool is audited before it goes live. A breach or a tripped four-fifths threshold triggers an immediate ad hoc review rather than waiting for the next scheduled one. Put these dates in the same calendar system the business already uses, with owners attached, because a cadence that lives only in a policy document is a cadence that will be missed.

Where the company hires in New York City and uses an automated employment decision tool, the annual audit is not just good practice, it is the law. Local Law 144 requires an independent bias audit of the tool conducted within the prior year, publication of a summary of the most recent audit results, and notice to candidates at least 10 business days before the tool is used, stating the qualifications and characteristics the tool assesses. David's cadence and his candidate-notice clause are written to satisfy this directly, and the 10-business-day requirement is why notice appears as a clause with a consequence rather than as a courtesy in a template.

The framework also references the broader legal frame the committee operates within: the EEOC adverse-impact standard and four-fifths rule, the ADA duty to provide accessible assessments and accommodations, and, for any EU candidates, the GDPR rights around solely automated decisions and the EU AI Act classification of recruitment and selection systems as high-risk, with its obligations for human oversight, transparency, and record-keeping. The committee does not interpret these alone; the Legal seat owns confirming the specifics for your jurisdictions and your role mix. Name the obligations in the document rather than gesturing at "applicable law," because a named obligation can be assigned an owner and a clause, and an unnamed one cannot.

Part Six: The Training Curriculum

A framework only governs behavior that people know they are supposed to exhibit, so the last drafted component is a curriculum that teaches each group its own duties. David outlines it by audience rather than by topic, because a single all-hands session that covers everything teaches nobody their specific obligations. Committee members need the decision matrix, the evidence standards for approval, and their suspension authority. Tool owners need the monitoring calculation, the monthly review, the audit process, and the escalation clock they are on. Recruiters and hiring managers need the human-oversight rule, the notice and accommodation obligations, and how to raise a concern.

Delivery follows the audience. The committee and tool owners get a working session where they run the approval process on a real tool, because those duties are procedural and are learned by doing them once with support. Recruiters and hiring managers get a short module attached to the moment of relevance, at tool provisioning and at annual refresh, since training delivered months before a duty applies is training that will not be recalled when it does. The Legal seat teaches the regulatory portion; the tool owners teach the monitoring portion. Someone who performs the duty is usually the right teacher, and it is the cheapest way to keep the curriculum current as the framework changes.

Effectiveness is measured on behavior rather than attendance, which is the point most training plans miss. Completion rates tell you people sat through it. What David tracks instead is whether approval requests arrive with the required evidence attached, whether monthly reviews are completed on time, whether concerns are raised through the protocol at all, and whether notice clauses are being applied on live requisitions. Each of those is a signal that the training landed, and each maps back to a clause, so a persistent failure tells you which module to rewrite. A sample module makes the outline concrete: for tool owners, a sixty-minute session that walks through one real tool's fairness data, computes selection rates by group, applies the four-fifths comparison, and ends with each owner scheduling their own first monthly review.

Part Seven: Rollout, Communication, and Feedback

David plans the rollout in stages rather than launching everything at once. First, brief executives on the framework and secure sponsorship, because a governance body without visible executive backing loses its first real argument with a division that wants a tool. Second, train the committee and tool owners on their specific duties. Third, communicate the candidate-facing commitments and update the notices. Fourth, pilot the approval and audit process with one tool before applying it across all divisions, which surfaces the practical friction while the stakes are low.

Each audience needs a different emphasis on the same document. Executives hear the risk posture and the fact that a named committee now owns a class of exposure that was previously unowned. Recruiters and hiring managers hear what changes in their week: which requests now need approval, what they must confirm at AI-touched stages, and who to call. Candidates hear the transparency commitments in plain language on the careers site and in the notice itself. Legal, data, and IT partners hear the control mechanisms: the inventory, the audit requirement, the evidence standards, and the committee's authority to say no.

Finally, build the feedback mechanism into the rollout rather than promising a review later. David commits to a fixed point, one quarter in, at which the committee reviews what the framework has actually produced: how many approval requests came in, how many concerns were raised, which clauses proved unworkable, and where the pilot generated friction that will not scale. Frameworks are drafted with imperfect knowledge of how the work really runs, and the ones that survive are the ones with a scheduled, owned revision cycle. A governance framework that arrives as a surprise mandate gets resisted; one that arrives with sponsorship, training, a pilot, and a visible way to be corrected gets adopted.

Your Deliverable

What you should finish with is a document of a few pages, not a deck: the committee's seats, powers, and decision matrix; three to five testable principles; the policy clause set with a role, requirement, and consequence in every row; the escalation protocol with entry points, owners, and clocks; the audit calendar with named obligations attached; the training curriculum by audience with its effectiveness measures; and the rollout sequence with a scheduled review date. Then run one test on it before you circulate it. Pick the AI tool in your function with the least documentation behind it, walk it through your own approval clause, and see what happens. If your draft would require suspending a tool your business currently depends on, you have learned something important about either the clause or the tool, and it is far better to learn it now than in front of a regulator.

Anti-Patterns

Principles written as slogans. This is a framework opening with "we use AI ethically and responsibly, with fairness at the center," and nothing downstream that could ever be measured against it. It happens because values language is easy to agree on and specific commitments have to be negotiated. What goes wrong is that the principles section becomes a preamble everyone skips, and the first genuinely hard decision, a tool that performs well but cannot explain itself, gets argued on instinct because no principle rules on it. The counter is the drafting test: for each principle, name a specific decision it would change, and cut the ones that cannot answer.

Clauses with no consequence attached. Here the policy states a requirement and stops, so a breach produces a conversation at best. It happens because writing the consequence forces a negotiation with whoever would have to apply it, and that conversation is easy to defer to a later draft that never comes. What goes wrong is public: the first time a tool is deployed without approval and nothing happens, every other clause is downgraded to advice in the mind of everyone watching. The counter is structural, a fixed three-element clause format, and a rule that any requirement whose consequence you would not actually apply is demoted to encouraged guidance.

A committee that can only advise. This is a governance body with cross-functional membership, a regular meeting, and no power to stop anything. It happens when governance is created to satisfy an audit finding rather than to control a risk, and it is often visible in the charter's verbs: review, recommend, provide input. What goes wrong is that the committee becomes a queue that decisions pass through on their way to being made elsewhere, and its documented concerns turn into evidence that the organization knew and proceeded anyway. The counter is to write the three powers explicitly, approve, review, suspend, and to give the chair interim suspension authority so the most important one is usable between meetings.

Adopting a template framework unedited. This is lifting a published governance model, changing the company name, and circulating it. It happens because a polished template looks more authoritative than your own draft and saves a week. What goes wrong is that the template names roles you do not have, sets cadences your volume cannot sustain, and omits the jurisdictions you actually hire in, so the first quarter produces a stack of missed obligations and the framework is quietly abandoned as unrealistic. The counter is to draft the structure from your own org chart, tool inventory, and hiring footprint, and to use templates only as a checklist of what to consider.

A framework nobody was taught and nobody can find. The document is approved, filed, and never converted into anyone's actual duties. It happens because drafting feels like the deliverable and rollout feels like administration. What goes wrong is that recruiters continue as before in good faith, the first breach is genuine ignorance rather than defiance, and enforcing a consequence against someone who was never trained is both unfair and unsustainable. The counter is to treat the curriculum and the rollout sequence as parts of the framework rather than as follow-up work, and to gate tool access on training completion so the two cannot drift apart.

Practice

• Build your tool inventory first. List every AI tool touching your hiring process, including the unofficial ones, and for each record the owner, the stage it touches, whether it evaluates candidates, and whether any bias audit exists. You cannot govern what you have not enumerated, and the gaps in this list will drive the first quarter of your framework's work.
• Draft the decision matrix as a grid. Write the rows for adopting an evaluating tool, changing an approved one, adopting a low-risk tool, and suspending after a finding. Name who approves and what evidence is required in each case. Then find a real past decision in your organization and check which row it would have landed in.
• Write four principles and test each one. For every principle, name a specific decision it would have changed and a clause it maps to. Delete any principle that fails both tests, however good it sounds read aloud.
• Write three clauses consequence-first. Pick your three highest-risk practices, write the enforcement consequence before the requirement, and notice which ones you cannot finish. Those are the areas where your organization has not yet decided what it is willing to do.
• Draw the escalation flowchart and walk a real concern through it. Take a plausible complaint, a candidate asking why they were rejected by a tool, and trace it: who receives it, by when, who assesses, what triggers committee involvement, what the outcome options are, and who tells the person what happened. Every unmarked branch is an undesigned part of your protocol.
• Outline training by audience, not by topic. For committee members, tool owners, and recruiters or hiring managers, write what each must be able to do afterward, who teaches it, when it is delivered, and the behavioral signal that will tell you it worked.

Reflection

• If someone deployed an AI screening tool in your organization next week without telling anyone, how would you find out, and how long would it take?
• Which of your draft clauses would you actually enforce against a senior leader's preferred tool, and which would you quietly let slide?
• Who in your organization can suspend a tool today without convening a meeting, and does everyone know that?
• How would a candidate raise a concern about an automated assessment, and what would happen to it after they did?

Glossary

• Governance framework. The structures, principles, and policies determining how AI is evaluated, approved, monitored, and retired in a function, and who is accountable when it fails.
• Governance committee. The cross-functional body holding the three operative powers: approving tools before deployment, reviewing audit results on a cadence, and suspending a tool when policy is breached.
• Decision matrix. The grid stating, for each class of decision, who approves it and what evidence is required, so that authority never depends on interpretation of an org chart.
• Accountable tool owner. The single named person responsible for one tool's documentation, monitoring, and audit. One name per tool is what makes accountability real.
• Policy clause. The three-element unit of a framework: an accountable role, a stated requirement, and an enforcement consequence. A clause missing the third element is a preference.
• Required, prohibited, encouraged. The three honest categories of policy language. The first two carry consequences and are auditable; the third is guidance, and labeling it as such protects the other two.
• Escalation protocol. The documented path from a raised concern to a written outcome, with entry points, owners, decision timelines, and a duty to inform whoever raised it.
• Interim suspension authority. The chair's power to suspend a tool between committee meetings, exercised on the record, which keeps the framework's most consequential power usable at the speed problems occur.
• Independent bias audit. An external assessment of a candidate-evaluating tool's selection rates by group, required before deployment and at least annually under this framework, and required by law in some jurisdictions.
• Four-fifths rule. The EEOC standard treating a group's selection rate below 80 percent of the highest group's rate as a flag for investigation. It is the calculation the monthly review and the audit both apply.
• Automated employment decision tool. The category of system that computationally screens, scores, or ranks candidates, and the category that regulation such as Local Law 144 attaches obligations to.
• Local Law 144. The New York City requirement for an independent bias audit conducted within the prior year, publication of a summary of the most recent results, and candidate notice at least 10 business days before use, stating the qualifications and characteristics assessed.
• Vendor accountability clause. The contractual requirement that a vendor supply bias-audit data, model documentation, and cooperation with independent audits, enforced at renewal.

Related Lessons

• Governance Structures: Committees, Roles, and Decision Authority develops the committee design, seat composition, and authority questions this project turns into a matrix.
• Policies for AI Use: What Should Be Required, Prohibited, or Encouraged? is the source of the three-way policy vocabulary the clause set depends on.
• Ethical Guidelines: Values-Driven Principles for AI in Talent covers how organizational values become the testable principles in part two.
• Remediation and Escalation: When and How to Act on Findings extends the escalation protocol into what a confirmed finding obligates you to do next.
• Third-Party Tools and Vendors: Due Diligence and Contracts supplies the evidence standards behind the vendor accountability clause.
• Training and Capability Building: Ensuring Staff Can Use AI Responsibly goes deeper on the curriculum design sketched in part six.

Closing

David's framework did not make his company's AI use perfect, and that was never the goal. What it did was replace an unanswerable question with an answerable one. Before it, "who approved the video platform and was it audited?" had no owner and therefore no answer. After it, every tool has a named owner, an approval record, an audit date, and a review on the calendar, and the honest answer to the legal team's question is a document rather than an apology.

The parts of this deliverable that will be tempting to skip are the ones that carry the weight: the consequence in every clause, the clock in the escalation path, the interim suspension authority, the training that turns duties into behavior, and the scheduled review that lets the framework be corrected instead of abandoned. Draft those and you have governance. Draft everything else and you have a document that will be quoted approvingly in a meeting and ignored the same afternoon.

Key Takeaways

• Govern cross-functionally or pay for it later. A committee with Legal, Data, HR, and IT seats and a clear decision matrix prevents the siloed tool choice someone else has to unwind. Each tool needs one named accountable owner, because diffuse accountability is no accountability.
• Write principles as testable commitments. Three to five is the right range. For each, name a decision it would have changed, and map it to a clause and an enforcement step.
• Every policy clause needs a role, a requirement, and a consequence. Write the consequence first, make it something a system or a person can actually do, and demote to encouraged guidance anything you would not really enforce.
• Give the committee real powers and keep suspension usable. Approve, review, and suspend are the three powers; interim suspension authority for the chair is what stops a confirmed problem from running until the next meeting.
• Put a clock on escalation and close every concern in writing. Multiple entry points, an acknowledgement and assessment deadline, a committee decision deadline, a written outcome, and a duty to tell whoever raised it.
• Make the bias audit a standing calendar item. Monthly fairness checks against the EEOC four-fifths rule, quarterly committee review, and a full independent bias audit before deployment and annually thereafter.
• Build the law into the cadence by name. NYC Local Law 144 requires an annual independent bias audit, published results, and 10-business-day candidate notice for automated employment decision tools. The EEOC standard, the ADA, GDPR, and the EU AI Act each add obligations the Legal seat must confirm.
• Train by audience and roll out in stages. Teach each group its own duties, measure effectiveness on behavior rather than attendance, gate tool access on training, and pilot with one tool before going wide, with a scheduled review that lets the framework be corrected.

Frequently Asked Questions

We are a small team with no legal department. Is this framework overkill? The structure scales down, the obligations do not. A five-seat committee may become two named people who meet monthly, and the training curriculum may be a single session, but the elements that carry the weight stay: one accountable owner per tool, a written approval step before an evaluating tool goes live, a bias-audit requirement, candidate notice, and an escalation path with a clock. The legal obligations are set by where you hire and what your tools do, not by your headcount, so a small employer using an automated employment decision tool on New York City candidates faces the same audit, publication, and notice requirements as a large one. Where you have no in-house counsel, name the external counsel or advisor who owns the Legal seat's confirmations rather than leaving that row of the matrix empty.

What if a business leader deploys a tool anyway, in breach of the framework? This is the moment the framework is actually decided, and it usually happens once, early, and in public. Apply the clause as written: suspend the tool, log the deployment as a breach, and take it to the committee with the rationale documented. The instinct to make an exception for a senior sponsor is understandable and it is fatal, because everyone watching learns in a single afternoon that the policy binds people without leverage. If the clause turns out to be genuinely unworkable in that case, the correct response is to change the clause through the scheduled revision cycle, on the record, not to leave a written rule standing while quietly not applying it.

Do we need to publish our governance framework externally? The framework itself is an internal operating document and there is no general obligation to publish it. Specific components are a different matter: Local Law 144 requires publication of a summary of the most recent bias audit results and candidate notice at least 10 business days before an automated employment decision tool is used, stating the qualifications and characteristics assessed, and your candidate-facing commitments on transparency and accommodation need to be visible where candidates will encounter them. Draft with that split in mind. Keep the decision matrix, clause consequences, and escalation internals internal, and write the candidate-facing commitments in plain language you would be comfortable seeing quoted back to you, because that is precisely what will happen.