Draft AI Policy

This is a working draft. We are publishing it early and in the open, in the same spirit as our privacy statement, because policy about AI should itself be developed transparently, not announced as a finished artefact. When something changes we update this page and the date at the top.

Applies to: The Mantle Collective Owner: Phil Rust (AI Policy Owner); see the Collective for the current Founder Collective roster Version: 0.1 · 19 July 2026 · Next review: within 12 months, or sooner if a new AI capability enters Collective workflows or a Critical-band risk event occurs

This document reflects our position as at July 2026. It draws on current EU AI Act, NHS DTAC, UK Government AI Playbook, and CSA AICM guidance, and will be reviewed as that guidance evolves.

1. Intent: Why We Use AI This Way

Deliberately Section 1, not a preamble. Every clause below traces back to this: if a clause can't be justified by an Intent statement, it doesn't belong in the policy.

The Mantle Collective, not a legal entity, a founder-led community of practice, exists to help people move from passivity to proactivity, building active, intentional partnerships with AI that expand human capability rather than erode it. That conviction governs how we use AI ourselves, not just what we teach others.

Our positive commitments (falsifiable: each one is checkable, not aspirational):

AI multiplies judgement; it does not replace it. For every AI use in Section 6's High-risk tier, a named human role (Section 5) is accountable for reviewing the output before it reaches a beneficiary, mentee, or the public. This is checked at each policy review (Section 10), not asserted as an absolute guarantee we may not have headcount to honour.
We do not offload thinking we should be doing ourselves. AI drafts, summarises, and accelerates research. It does not make the final call on anything that shapes a relationship, a mentoring outcome, or public-facing judgement.
Every AI-assisted output we publish is disclosed as such, in keeping with our "co-created thought leadership" model; transparency about method is part of the message.
We use AI to widen access, not narrow it: accelerators and playbooks stay in plain language precisely so AI fluency isn't a prerequisite for benefiting from the Collective's work.

2. Purpose & Scope

Purpose: to give founders, contracted facilitators, mentors, and the broader Collective a single, clear reference for how AI may and may not be used in Collective activity, so decisions are made before pressure arrives, not during it.

Scope: covers all AI tools (generative AI, AI-assisted search, AI-drafted content, AI used in outcome assessment or programme-eligibility decisions) used in the Collective's name, by founders, contracted facilitators, and mentors acting in a Collective capacity (see Section 3's Core/Broader distinction), and by members of the broader Collective who choose to align with it. Does not govern mentees' or beneficiaries' personal AI use outside Collective activity.

Legal-scope trigger, not a static disclaimer: the EU AI Act binds a UK-only actor only if a system is placed on the EU market, put into service in the Union, or its output is used in the Union (Article 2). Being a "deployer" in the abstract (Article 3) is not, on its own, enough. This means scope can change as the Collective grows: a UK-only actor today crosses the trigger silently unless someone checks. We do not treat this as a one-time disclaimer: the AI Policy Owner re-checks the Article 2 trigger at each policy review (Section 10) and whenever EU-facing activity, EU members, or EU beneficiaries are newly onboarded; the check is tied to the event, not the calendar, so scope status can't go stale between reviews.

Stated assumption (owner: AI Policy Owner, recheck at every review): this document assumes Annex III standalone high-risk obligations apply from 2 December 2027, per the EU Digital Omnibus deferral reported as agreed by Council and endorsed by Parliament in June 2026, not the original 2 August 2026 date. The exact procedural dates and sequencing are flagged as unverified: the direction of the change (deferral, not the original date) is the load-bearing fact here, not the specific day. This is a live legislative area; the AI Policy Owner confirms the current position at each review rather than trusting any date in this document to still be accurate.

3. Definitions

AI: any system that generates, classifies, predicts, or recommends based on patterns learned from data, including generative AI (text/image), AI-assisted search, and AI features embedded in third-party tools.
Human oversight: a named individual with the authority and context to review, override, or withhold an AI-influenced output before it takes effect.
AI-assisted vs. AI-generated: assisted means a human materially edited and takes authorship of the output; generated means substantially unedited AI output is used as-is.
Core: founders, contracted facilitators, and mentors formally engaged by the Collective. This policy's rules are a condition of that engagement, not optional for them.
Broader Collective: everyone else who participates (community members, contributors, informal collaborators). No employment or contractual relationship exists; participation is voluntary. This policy does not bind them by force; see Section 11.

4. Principles

Adapted from the Open University's Responsible AI Policy and the UK Government AI Playbook, filtered through Section 1's Intent statement.

A note on tone: AI is not the risk here: unsupervised, unreviewed use is. These principles exist the way oven gloves exist: not because the oven is dangerous in itself, but because handling something powerful without the right precaution burns you.

Do

Do treat AI as a thinking partner that sharpens judgement, not a replacement for it (Section 1).
Do assign a named accountable person to every AI-assisted decision (Section 5).
Do disclose AI involvement in anything published or beneficiary-facing.
Do scale the depth of review to the impact of the decision (Sections 6-7): proportionate, not applied uniformly to trivial and high-stakes uses alike.
Do confirm a lawful basis before any personal data enters a third-party AI tool (Section 8).
Do apply this policy alongside, never instead of, existing Safeguarding, Prevent duty, and Information Governance (IG) policies. Where they conflict, the more protective clause governs.
Do escalate uncertain cases upward rather than guessing (Section 5).
Do treat every AI-assisted task as a learning opportunity. Knowledge and experience should compound through AI use, not erode: if a task leaves you no more capable than before it, ask whether AI did the thinking you should have done yourself (Section 1). Heavy AI users should draw on the Collective's Role and Skills Library, and the mentor-matching partner organisation the Collective refers members to, keeping this compounding real rather than assumed.
Do protect human capacity from AI-accelerated pace. AI output scales; human judgement, attention, and recovery don't scale the same way. Where AI use measurably accelerates the pace of work, the Collective commits to converting some of that gain into capacity protection, adjusted working times, workload recalibration, or reduced concurrent caseload, rather than treating the full gain as extra throughput. Proportionality: the AI Policy Owner sets, in advance and in writing, what counts as a trivial capacity gain for the coming review period, never judged in the moment by whoever would benefit from skipping the adjustment.
Do make AI use observable: for learning first, audit second. Do #8's compounding and Do #9's capacity protection are both unverifiable claims without data behind them. Section 8's log is captured once; Section 10 defines how it's read two ways so honest reflection and formal audit don't compete for the same record.

Don't

Don't let AI make a final decision affecting a person without a named human able to override it (High-risk tier, Section 6).
Don't attempt to circumvent, "jailbreak," or adversarially prompt an AI tool's built-in safety measures to obtain output it is designed to refuse. A refusal is signal, not an obstacle to route around. Scope note: this covers defeating a tool's own guardrails, not the ordinary scope limits of Section 6, and not using AI against unrelated third-party systems (an IT-misuse matter, handled outside this policy).
Don't let AI use increase a mentee's dependency or diminish their own developing judgement, even when it is more efficient.
Don't allow an AI-driven outcome to disadvantage any group the Collective serves without checking for it first.

Exception: Break-glass, pressure relief over polish

Below the High-risk tier only, where the ordinary review process would itself add pressure that harms a person (e.g. a delay during a personal crisis, a mandatory second-reviewer nobody is available to be), a lighter or unreviewed AI-assisted output may be used instead of applying full process. This is an exception, not a standing option: every use is flagged to the AI Policy Owner (Section 5) in the moment (one line is enough), and reviewed at the next policy review (Section 10). It never applies to High-risk or Prohibited uses, where quality and oversight are the point regardless of pressure.

5. Governance & Roles

Every AI-policy failure traces to unowned decisions. This section exists to make ownership explicit, not decorative.

Modelled on the Three Lines of Defense, the standard governance pattern for risk-based organisations, combined with OKR-style localisation: each layer adapts the policy to its own context, but must show how the local version still serves the layer above, not just relay it downward unchanged.

Line	Role	Owns	Localises by
3rd: Assurance	Founder Collective (the founders, collectively, no board exists, since there is no legal entity)	Risk appetite, ratification, receiving escalated risks ≥ threshold (Section 7)	Sets the boundary every layer below localises within
2nd: Framework	AI Policy Owner (named individual, drawn from Core, Section 3)	Policy content, review cadence, cross-section fidelity, first point of escalation	Translates risk appetite into concrete, applicable rules
1st: Operational	Section/Working-group Leadership (one per team or function)	Applying and localising the policy to their section's actual workflows; day-to-day risk in their area	Adapts rules to local practice: must show which Principle (Section 4) the local version instantiates
Front line	Core (bound) and Broader Collective (voluntary, Section 3)	Applying the policy day-to-day, flagging uncertain cases upward rather than guessing

Named for now: Phil Rust holds the AI Policy Owner role (2nd line) for this draft. The Founder Collective (3rd line) is the current roster published at the Collective; as the Collective grows, Section/Working-group Leadership (1st line) will be named there too.

Fidelity check: every Section Leadership localisation carries a one-line trace back to the Principle or rule it instantiates, reviewed by the AI Policy Owner at the policy review cadence (Section 10). A local adaptation that can't show its trace is treated as drift, not a localisation.

Conflict of interest, separation of duties when lines overlap: in a founder-led org, the 2nd and 3rd lines are often the same people as the 1st. This is a genuine gap, not a paper risk. For any Critical-band or Impact=5 decision (Section 7), review must include at least one person outside the immediate working group, and, where the decision reaches the Founder Collective itself, at least one named external reviewer (a non-Core advisor, a peer organisation's AI Policy Owner, or equivalent). The Collective will name a standing external-reviewer pool as this policy matures past draft. Fallback: if no qualified external reviewer responds within 5 working days, the decision proceeds with a logged exception, flagged for retrospective external review at the next opportunity; it does not block indefinitely.

6. Risk Classification: Permitted, Restricted, Prohibited Uses

Two different tier systems appear below, and they must not be read as one. Mantle Tier is this Collective's own policy choice: it can be, and deliberately is, stricter than any external law requires. EU AI Act Classification is that Regulation's actual legal category, shown for readers who check, so a Mantle Tier of "Not permitted" is never mistaken for a legal finding that the practice is Article 5-banned when it may in fact be a permitted-but-regulated Annex III High-Risk system that Mantle simply chooses not to run unsupervised.

Mantle Tier	Example Collective use	EU AI Act Classification (if in scope, see Section 2)	Rule
Not permitted (Mantle policy)	AI used to make a final decision on an individual's access to Collective programmes or resources (e.g. Skills Library admission, business-support eligibility) with no human review; AI used to assess a beneficiary without disclosure	Arguably Annex III High-Risk (education/vocational training, Point 3, access/admission to training/development resources). Legally permitted-with-heavy-obligations if it applies, not Article 5-banned. Whether this actually meets Annex III's threshold at the Collective's scale is a real legal question, not asserted flatly here. Mantle's own bar is stricter than the legal minimum either way.	Not permitted under this policy, no exceptions
High-risk (heavy review)	AI-assisted drafting of independent outcome assessments (six/twelve-month reviews)	Also Annex III High-Risk: human oversight (Article 14) is a compliance obligation on an already-high-risk system, not something that declassifies it out of High-Risk	Human oversight mandatory, documented, reviewable
Limited (transparency only)	AI-assisted drafting of playbooks, articles, co-created content	Limited-risk, Article 50 transparency obligation	Disclose AI involvement per Section 1's transparency commitment
Minimal	AI-assisted internal scheduling, note summarisation	Minimal-risk, no mandatory obligations	No formal process required

A note the correction above must not overstate: Article 6(3) does provide a real derogation for genuinely narrow procedural or preparatory tasks that don't materially influence the outcome. This doesn't apply to the "final decision, no human review" case above (which is precisely what the derogation excludes). Article 6(3)'s final subparagraph holds a system "always" high-risk where it performs profiling of natural persons, and most plausible mentor/candidate-ranking uses are profiling, which likely defeats the derogation even for narrower-seeming tasks. Treat the derogation as a route to check case-by-case with real legal input, not a default assumption either way.

"Not permitted" means different things for Core and Broader Collective (Section 3); see Section 11 for how each tier is actually upheld without an employer's enforcement power.

7. Risk Assessment & Escalation

Each new AI use is written as a risk statement: "Because [use], there is a risk that [mechanism], which could cause [impact], affecting [stakeholder]."

Scoring: Impact × Likelihood, both 1-5. Banding: Low 1-4 · Medium 5-9 · High 10-15 · Critical 16-25. Override: any risk with Impact = 5 escalates to the Founder Collective regardless of the multiplied score; a rare-but-catastrophic risk must not hide behind a low likelihood.

Escalation threshold: Critical band (16+) or Impact = 5 → Founder Collective. High band (10-15) → AI Policy Owner reviews and documents; escalates to the Founder Collective only if unresolved.

Starter generic risks (fire conditionally, adapt firing condition per use):

Risk	Fires when...	Default Impact / Likelihood
AI-generated advice presented as human judgement without disclosure	Any public or beneficiary-facing AI-assisted output exists	4 / 3
Data used to prompt an AI tool leaves the org's control boundary	Any third-party AI tool is used with personal/sensitive data	4 / 3
Over-reliance erodes the human skill AI was meant to multiply	AI is used repeatedly for the same judgement-task without review	3 / 4
AI-accelerated pace outstrips human capacity to sustain it (Do #9)	AI use measurably increases throughput or volume expectations without a compensating capacity adjustment	4 / 4
AI vendor's infrastructure is unassessed	Any paid/third-party AI tool is adopted without a vendor check	3 / 3

8. Data Protection & Technical Controls

For anyone evaluating an AI tool or vendor, the relevant CSA AI Controls Matrix (AICM v1.1) domains to check are: Data Security & Privacy Lifecycle (DSP), Identity & Access Management (IAM), Cryptography, Encryption & Key Management (CEK), Model Security (MDS), the domain AICM adds beyond standard cloud security, covering model-specific risks (prompt injection, training data provenance, output integrity), and Logging and Monitoring (LOG), which underpins the observability commitment in Section 10.

No Collective data classified as personal or sensitive enters a third-party AI tool without confirming: a lawful basis exists, the vendor's data-retention terms are known, and the tool does not train on submitted data by default (or this has been explicitly disabled).

Logging: Core members (Section 3) deploying generative AI or automated matching/assessment tools within Collective workflows keep a basic log of inputs and decision outputs for a minimum of six months; this is a floor, matching Article 19/26(6)'s minimum where relevant, not a target. This is proportionate good practice regardless of EU AI Act scope, not an admission that scope has been triggered.

9. Training & Awareness

Every person covered by this policy's scope completes a short onboarding covering Sections 1, 4, and 6 before independent AI use in Collective activity. This is itself an expression of Mantle's mandate: AI literacy is part of the intergenerational investment the Collective exists to provide, not a compliance chore layered on top of it. It also happens to be informed by the EU AI Act's Article 4 AI-literacy duty (in force since Feb 2025, binding regardless of tier), cited here as good practice this Collective would follow anyway, not as an acknowledgement of legal obligation.

10. Monitoring, Review & Evaluation

Reviewed at minimum annually, or triggered by a new AI capability entering Collective workflows, or after any Critical-band risk event. Review updates the risk library (Section 7), re-confirms the named Policy Owner, checks Section 4's pace-protection commitment (Do #9) against how work pace has actually changed since the last review, and re-checks Section 2's Article 2 trigger against any new EU-facing activity, members, or beneficiaries, not just whether the policy text still reads well.

Observability & metrics (Do #10): one capture point, two interfaces, not two logging systems. Section 8's log (inputs, decision outputs, minimum six months) is the single source. It is read differently depending on purpose, because formal, attributable capture and honest, reflective learning structurally compete for the same record if not deliberately separated:

Audit view: raw, attributable, immutable. Feeds Section 11's peer verification and Section 7's escalation. This is what a governance review or an external check would see.
Learning view: de-identified and aggregated before it reaches any learning forum. No individual is named in a learning discussion of what the data shows. This is what protects the psychological safety Do #8's compounding actually depends on: a person who fears their corrections will be read as a performance record will stop logging honestly, which quietly breaks both interfaces at once.

What gets measured, and what doesn't:

Human learning signal: correction-effort on AI-assisted output, tracked per person over time (learning view only). Falling correction-effort on similar tasks is compounding (Do #8) working; flat or rising effort alongside rising AI-use volume is the dependency Do #8 exists to catch; volume alone is not a learning metric.
Workflow-improvement signal: rework rate per tool or prompt-pattern, tracked by Section Leadership. A Section retiring a tool because its logged rework rate stayed high is the workflow improving. This policy does not claim the AI itself improves: the Collective doesn't train models; what improves is which tools, prompts, and processes a Section chooses to keep using.

Reviewed at the same cadence as the rest of this section, not a separate observability review, so it doesn't quietly become a fifth thing nobody has capacity to run.

11. Compliance, Breach & Integration with Other Policies

There is no legal entity and no HR department behind this policy for most of the people it touches. For Core (Section 3), this policy is a condition of formal engagement: breaches follow whatever contract or engagement terms are in place, the closest available equivalent to a disciplinary process. For the Broader Collective, adherence is voluntary: members are free to act as they will. This policy does not, and cannot, stop them.

What this policy does do is define what earns the benefit of being visibly aligned with the Collective: referral into the (outsourced) mentor-matching partner's programme, use of the Mantle name and branding, inclusion in co-created thought leadership, the founder network's referrals. Non-adherence doesn't trigger discipline; it means those benefits aren't extended or are withdrawn. This mirrors Section 1's own conviction: even adherence to this policy should be chosen, not coerced, or the document would be arguing for human agency while denying it to its own readers.

For this to hold real weight rather than becoming a hope nobody checks: adherence is tracked via a public register, checked by peer verification within Sections/working-groups rather than central enforcement (there is no centre to enforce from). A signed pledge with no visible register and no withheld benefit is motion without effect; this policy deliberately avoids that. Capture and synthesis are split, to keep this sustainable at founder-led capacity: entries are appended in real time, one line, no assessment required ("[who], [what changed], [date]"), cheap enough to actually happen; synthesis, curation, and the public-facing page explaining what "alignment" means in practice are produced at the policy review cadence (Section 10), not continuously.

Consistent with Section 4's Do #6, this policy sits alongside, not instead of, Data Protection, Safeguarding, Prevent duty, and Information Governance (IG) policies; where they conflict, the more protective clause governs.

12. Transparency & Public Commitment

Consistent with Section 1's disclosure commitment: the Collective publishes a plain-language summary of this policy publicly, in keeping with the "voice" pillar of its own mission, demonstrating the model in the way it is made, not just describing it.

13. References & Version Control

UK GDPR / Data Protection Act 2018 / ICO guidance: applies to any personal data the Collective processes regardless of legal form; this policy is informed by, not a substitute for, existing Data Protection practice
No Charity Commission or Companies House registration: the Collective is not a legal entity; there are no statutory trustee duties to reference. Governance runs through the Founder Collective (Section 5) and the benefit-of-adherence model (Section 11) instead of statutory duty
EU AI Act (Regulation 2024/1689): risk-tiering model borrowed as structure; a UK, non-legal-entity collective is not assumed bound by it (Article 2 scope test)
NHS DTAC: five-domain vendor assurance structure (for any AI vendor touching care-adjacent work)
UK Government AI Playbook (DSIT, Feb 2025): 10 principles, staged lifecycle
CSA AI Controls Matrix (AICM v1.1, July 2026): 18-domain technical control surface
Structural precedent: Open University Responsible AI Policy; Sheffield Hallam AI Policy; Action for Happiness AI Policy; Pilotlight Responsible Use of AI Policy; Charity Excellence AI Policy Template

Version	Date	Change
0.1	2026-07-19	Initial published draft