Does Article 27 apply to us before we switch on a high-risk AI system?
Article 27 applies only to specified deployers of Annex III high-risk systems, and only before first use. If you are a body governed by public law, a private entity providing public services, or a deployer of credit scoring or life and health insurance pricing systems (Annex III points 5(b) and 5(c)), you must assess the impact of the system on fundamental rights before you switch it on. Critical infrastructure systems are excluded from this duty. Other deployers of high-risk systems are not caught by Article 27, though they still have Article 26 duties. The high-risk rules for Annex III systems now apply from 2 December 2027, so this is a planning date, not a switch-on date for most organizations today. Confirm the exact trigger with your counsel against the consolidated text, and check whether your system falls under Annex III at all.
The assessment asks you to describe, in writing, how you will use the system: the processes it supports, how long and how often it runs, which groups of people it will affect, the specific risks of harm to those people, the human oversight measures in place, and what you will do if a risk materializes, including governance and complaint routes. The risk it addresses is that a system which is accurate on paper still harms people through how it is deployed. The 2026 amendment lets you cross-reference or include parts of a GDPR data protection impact assessment, and the AI Office is to provide a questionnaire template and automated tool. Fundamental rights are a broad field, so scope the assessment to the rights your use case actually touches, such as non-discrimination, privacy and access to services.
The hard part is that much of the required content is about your business, not your model. Technical teams usually know the model, its inputs and its metrics, but rarely hold the detail on who is affected, how often decisions are made, what a complaint looks like in practice, or who can override an outcome. Start by assigning an owner from the business or legal function and collecting these facts before the technical review. Ask your provider for any earlier assessment it has prepared for similar cases, since Article 27(2) allows you to rely on it and update only what changes. Ask your implementation partner or assessor what evidence they will need to confirm each of the six elements.
Which deployers and systems must complete the assessment
Article 27 applies to a narrow group of deployers, so the first job is scoping: who the deployer is, which Annex III category the system falls in, and whether the system is already in use. Each card below is a decision point that changes whether the assessment is required and how much work it creates.
Bodies governed by public law
Article 27(1) covers deployers that are bodies governed by public law, such as ministries, public agencies and municipal bodies, when they deploy a high-risk Annex III system. The test is the body's legal status, not the sector it works in. Check whether the body is established under public law or funded and controlled by the state, and record that reasoning in the file. A public body that uses a scoring tool in its benefits or licensing work is in scope even if a private vendor built the tool.
Private entities providing public services
The second group is private entities that provide public services, a category that depends on the function being performed, not on who owns the company. Ask whether the entity delivers a service the state has entrusted to it, such as a regulated utility or a contracted public service. A private lender is not automatically a public service provider, so decide this per use case and document the basis. Scoping decisions here often determine whether the assessment is required at all.
Credit scoring and insurance pricing deployers
Article 27(1) also reaches deployers of AI used for creditworthiness assessment and credit scoring of natural persons, and for risk assessment and pricing in life and health insurance. These are the Annex III point 5(b) and 5(c) systems. Private lenders and insurers fall in scope through this route even when they are not public bodies, so an assessment is needed for these uses regardless of corporate status. Confirm the exact system function against the Annex III wording before concluding that a tool is out of scope.
Critical infrastructure exclusion
Annex III point 2 systems used as safety components in critical infrastructure management are excluded from the Article 27 assessment duty. Deployers should not assume the exclusion covers every infrastructure-related tool. Check whether the system is an Annex III critical infrastructure system and whether it is used in a way that fits the exclusion. Other Article 26 duties may still apply to the same system, so keep the scoping memo for both obligations.
First use as the trigger
The obligation attaches before first use of the system by the deployer, not when the system is bought or when the contract is signed. A system already in production when the obligation becomes applicable needs a documented position on whether it has been used in a way that requires the assessment. Confirm with counsel and the provider how the 2 December 2027 application date for Annex III systems applies to existing deployments, and record the dates used in the decision.
Reliance on earlier and provider assessments
Article 27(2) allows a deployer to rely on a fundamental rights impact assessment carried out earlier, including one the provider has done, where the use case is similar. The deployer must still check that its own processes, affected groups and risks match, and must update any element that has changed. Treat a provider assessment as a starting input, not a finished deliverable. Ask the provider for the assessment and the conditions under which it applies.
How to build the assessment step by step
The sequence below takes a deployer from confirming that Article 27 applies to a system through to notification and a review plan, so that each step produces a record an authority or auditor can read. Work through the steps in order, because later steps depend on the process description and the list of affected people.
Confirm scope and first-use date
Establish whether the deployer is a body governed by public law, a private entity providing public services, or a deployer of credit scoring or life and health insurance pricing systems, and whether the system is an Annex III high-risk system other than critical infrastructure. Record the planned first-use date, because the assessment must be completed before that first use. The output is a scope note signed by the accountable owner, stating the system, the deployer category and the Annex III point that applies.
Describe the deployer's processes
Document the business process in which the system runs, the decisions it informs or makes, and the people who operate it. Ask the provider for its instructions for use so that the description matches the intended purpose. The output is a process description that a reviewer outside the project team can follow from input to decision.
Set period and frequency of use
Record how long the system will run in each deployment, how often it is invoked, and which volumes or schedules apply. Note any planned changes in scale. The output is a usage profile table with period, frequency and volume, which later feeds the risk review and the update triggers.
Map categories of affected people
List every group of natural persons who may be subject to the system's outputs, including applicants, customers, policyholders, employees and, where relevant, vulnerable groups. Confirm the groups with the business owner and, where possible, with a representative of those groups. The output is a register of affected categories with the decision each group is exposed to.
Identify specific risks of harm
For each affected category, identify the specific risks of harm to fundamental rights, such as discrimination, exclusion from a service or unfair pricing, and rate likelihood and severity with a documented method. Use the provider's known limitations and the data sources as inputs. The output is a risk register linking each risk to the affected category, the process step and the owner.
Document human oversight and response measures
Describe who reviews outputs, when a human can override or stop the system, and the training that reviewers receive. Then define the measures the deployer will take if risks materialize, including governance roles, escalation paths and complaint mechanisms that affected people can use. The output is an oversight and response procedure with named roles, plus a complaint route described in plain language.
Reuse earlier and provider assessments where allowed
Check whether the provider or another deployer has already produced an assessment for a similar use, and whether that work covers your processes, categories and risks. Reuse only the parts that match and record each gap you fill. The output is a reuse log that states the source of each reused element and the differences that you assessed yourself.
Decide the GDPR DPIA overlap
Where a GDPR data protection impact assessment is required or already exists for the same processing, decide which elements can be cross-referenced or included, and which must be written separately. Involve the data protection officer in this decision. The output is a mapping note that shows each Article 27 element and whether it is covered by the DPIA, with the reference to the DPIA section.
Approve, notify the authority and set update triggers
Obtain sign-off from the accountable executive and the data protection officer, then submit the results to the market surveillance authority using the filled-out template. Define update triggers such as a change in process, affected groups, data sources, or a substantial change in the provider's instructions. The output is an approval record, a copy of the notification and a review calendar linked to those triggers.
How an assessor tests the fundamental rights impact assessment
This table compares each element of the Article 27 assessment, the timing and reuse rules, and the GDPR overlap, showing what an authority reviewer asks for and where submissions usually fail. Read it as a checklist of the record you should hold before first use, since the authority reviews the filled-out template and the supporting file, not a certificate.
| Requirement | Evidence requested | Common findings |
|---|---|---|
| Article 27(1)(a): deployer processes | Process description showing where and how the system is used within the deployer's business, tied to the stated purpose | Generic description of the product that never names the actual business process or decision it supports |
| Article 27(1)(b): period and frequency of use | Stated period of use and frequency, with the operating environment and volumes that support those figures | Vague wording such as ongoing or as needed, with no link to real operating volumes |
| Article 27(1)(c): categories of affected people | List of groups affected by the system's outputs, such as applicants, customers or patients, with the basis for each | Affected groups omitted, or only the people who operate the system are listed |
| Article 27(1)(d): specific risks of harm | Risk entries specific to the deployment and to each affected group, with the likelihood and severity reasoning recorded | Risks copied from the provider's generic list with no system-specific or group-specific analysis |
| Article 27(1)(e): human oversight measures | Named oversight roles, the authority to override or stop the system, and training records for those staff | Oversight described as human in the loop without roles, override procedures or evidence of training |
| Article 27(1)(f): measures if risks materialize | Governance structure, escalation path, complaint mechanism and remediation steps, with owners and tested contact routes | No working complaint route for affected people, or measures that name no owner |
| Notification to the authority (Article 27(3)) | Filled-out template submitted to the market surveillance authority, with the date of submission and the results recorded | Assessment completed internally but never submitted, or submitted without the template in the form the authority requires |
| First-use timing (Article 27(1) and 27(2)) | Dated assessment completed before the first use of the Annex III system, with a record of the first use date | Assessment dated after go-live, or no evidence separating first use from later operation |
| Reuse of earlier assessments (Article 27(2)) | Earlier assessment, including the provider's, mapped to the deployer's own use case, with a note of what differs | Provider material copied in full without checking that the deployer's context and affected groups match |
| Updates after change (Article 27(2)) | Change log showing which elements were revised after a material change, with version history and reviewer sign-off | No record of update after a change in purpose, population, oversight or data source |
| GDPR overlap (Article 27(4) and 27(5)) | Cross-reference or included section from the GDPR data protection impact assessment, with the parts that cover the same elements identified | Duplicated text that is out of date, or a DPIA reference that does not cover the Article 27 elements |
Which evidence shows the assessment is complete and current
An Article 27 assessment is only as credible as the record behind it. The six artifacts below cover what was decided, what was known at first use, and what changed since, so an authority reading the notification can trace each claim back to a dated source.
Signed assessment record with six elements
This is the document that carries the assessment itself, organized around the six elements in Article 27(1)(a) to (f): processes, period and frequency of use, affected categories, specific risks of harm, human oversight, and measures if risks materialize. Check that each element has an owner, a date and a sign-off from someone accountable for the deployment. A record that leaves any element blank will not survive a reading against the article text.
Process and usage description
This artifact records how the system is actually run: the business process it supports, the decisions it informs, who operates it, and how long and how often it runs. Write it from operational logs and configuration rather than from the vendor brochure, and confirm it with the teams that use the system daily. Any change to volume, geography or decision type is a trigger for updating this description.
Affected-person and risk register
The register lists each category of people affected by the system, such as applicants, policyholders or patients, and maps each category to specific risks of harm and the mitigations for them. Keep one row per risk so reviewers can see which mitigation answers which concern. Review the register when complaints arrive, when the population changes, or when the model or its inputs are replaced.
Human oversight and complaint procedure
This procedure names the people who can review, override or stop an output, and it describes how an affected person raises a complaint and how that complaint reaches a decision-maker. Test it with a tabletop exercise before first use, and record the result. Confirm that the complaint route is the same one the deployer already uses for other automated decisions, so that affected people are not directed to two different channels.
Notification receipt or submitted template
Article 27(3) requires the deployer to notify the market surveillance authority of the results by submitting the filled-out template. Keep the submission, the authority's acknowledgement and the exact version of the template used. Confirm with the authority which template version is current, because the AI Office is developing the questionnaire and automated tool under the 2026 amendments.
Dated change log and version history
The change log proves what the deployer knew at first use and how the assessment evolved afterward. Store each version of the assessment in a system that records what changed, when and by whom, and that allows any two versions to be compared. Article 27(2) allows reliance on earlier assessments, including the provider's, so keep the provider's version alongside your own with its date. Version history is the strongest evidence that the first-use record was not rewritten later.
Which self-hosted open-source tools can hold the assessment
CISO Assistant is an open-source governance, risk and compliance platform released under AGPL-3.0-only. Its framework library includes more than 200 frameworks, among them GDPR, which matters for Article 27 because the 2026 amendment lets deployers cross-reference or include parts of a GDPR data protection impact assessment. Teams that keep both records in one place can track where the fundamental rights assessment and the DPIA cover the same processing, and where they diverge.
- Framework coverage: The library includes GDPR alongside the frameworks that many deployers already use, such as ISO 27001 and NIST CSF 2.0, so the AI Act record sits next to the controls it relies on.
- Automatic mapping: The platform maps between frameworks automatically. Confirm which mappings are shipped, how they were produced and whether your legal team accepts them as a basis for cross-referencing.
- Assessment tracking: It can run audits and compliance assessments against the loaded frameworks, which gives a place to record the six elements and their status.
- Licence obligations: AGPL-3.0-only requires you to review the terms before modifying the software or offering it to users over a network. Ask counsel to confirm how the licence applies to your deployment.
Confirm with your data protection officer and legal team whether the platform's mappings and assessment templates fit your process before you rely on them for evidence.
XWiki is an open-source wiki released under LGPL-2.1-or-later. Each change to a page is kept under version control, so the assessment document can show what changed, when and by whom. That history matters when an authority asks how the assessment was produced and whether it was updated after a change in processes, period of use or affected groups, as Article 27(2) requires.
- Change history: Every edit to a page is recorded with the time and author, giving a trail of how the six elements evolved.
- Version comparison: Reviewers can compare any two versions to see exactly what changed between a submitted assessment and a later update.
- Rollback: Users can restore an earlier version if a later edit was wrong, while the history of the mistake remains visible.
- Structured pages: Wiki pages can hold the assessment narrative, the risk register and the notification record, with links between related pages.
Confirm that the version history meets your retention and evidence rules, and decide who may approve a version before it is treated as the record filed with the authority.
BookStack is an open-source documentation platform released under the MIT licence. Its permission model controls who can edit the assessment and who can only read it. User abilities come from the roles assigned to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. That lets a team lock the final assessment for editors while giving reviewers and staff read access.
- Role-based abilities: Abilities are granted through roles, so editors, reviewers and read-only staff can be defined once and reused.
- Per-role overrides: Permissions can be set at the shelf, book, chapter or page level, for example to restrict edits to a single page holding the signed assessment.
- Read-only publication: Staff who need the outcome can view the assessment without rights to change it, which supports a clear record of who had write access.
- Separation of duties: Assigning the drafting and approval roles to different people can be configured through roles, if your governance process requires it.
Confirm that BookStack's role settings match your internal approval process and that access reviews are scheduled, since role assignments do not decide the assessment's content.
What a fundamental rights impact assessment costs in money and effort
This table compares the cost components of an Article 27 assessment, who is paid for each, whether the cost is one-time or recurring, and what drives it up or down. Use it to shape a written scope and to ask suppliers for a quote that separates each component. The main takeaway is that most of the effort sits in staff time and reuse of existing GDPR work, not in software.
| Cost component | Who carries it | One-time or recurring, and main drivers |
|---|---|---|
| Staff time from legal, risk and business owners | Deployer's own staff | Both. Initial scoping and risk description are one-time; annual review and updates when processes change are recurring. Drivers: number of affected groups and process steps. |
| Technical team time for system description | Deployer's engineers and the provider's documentation | Mostly one-time per system. Drivers: how much of the provider's instructions for use can be reused, and how well the deployer knows its own input data. |
| Legal or privacy review | Internal counsel or external lawyers | Initial review is one-time; review after material changes is recurring. Drivers: existing GDPR DPIA maturity and how often the assessment must be revisited. |
| External facilitation or consultant time | Consultant or implementation partner, under a written scope | Usually one-time for the first assessment, with optional recurring support. Drivers: internal experience with Article 27 and the number of systems in scope. |
| Tooling and licenses | Deployer, for any commercial governance platform | Licenses recur. Self-hosted open-source tools can remove some license spend but still need hosting, administration and backup effort. |
| Authority notification handling | Deployer's compliance or legal team | One-time per submission of the filled-out template, plus any follow-up requests from the market surveillance authority. Drivers: quality of the evidence pack. |
| Periodic update effort | Deployer's assessment owner and affected business teams | Recurring. Triggered when elements change, such as the period or frequency of use, affected groups, or human oversight measures under Article 27(2). |
| Reuse of earlier or provider assessments | Deployer, with provider cooperation | Reduces one-time effort. Drivers: whether the same system is used in similar cases, and whether the deployer can document what differs. |
| Exposure if the duty is missed | Organization as a whole | Article 99 sets maximum fines for most operator obligations at EUR 15 million or 3% of worldwide annual turnover, whichever is higher. Assessing cost against this exposure is the reader's decision. |
Who owns the assessment, who helps prepare it, and who checks it
Your organization owns the fundamental rights impact assessment under Article 27 of the AI Act. The deployer is the party that must carry out the assessment before first use of an Annex III high-risk system in scope, and that accountability cannot be transferred to a vendor or consultant. Your team decides how the system is used, who is affected, which risks are material and which oversight and complaint measures apply, and it signs off the results before they are submitted.
- Ownership of the assessment: Name an accountable owner, usually in risk, compliance or the business function that runs the use case, and document who approved the scope.
- Decisions on risks and oversight: Decide which harms are credible, how human oversight works in practice, and what happens if a risk materializes.
- Final risk acceptance: Record the residual risk decision and the rationale in a form that a supervisor can trace.
- Notification: Submit the completed template to the market surveillance authority under Article 27(3), and keep a copy of what was sent.
- Updates on change: Re-open the assessment when processes, affected groups or risks change.
Confirm with counsel which Article 27 duties apply to your entity type and which Annex III category your system falls under before you assign owners.
An implementation partner can prepare the systems, evidence and working records that your team uses to complete the assessment. DeployOpen prepares systems and evidence inside your own infrastructure. It does not write the legal conclusion on your behalf, does not issue an assessment report, and does not certify that the assessment meets the Act.
- Preparing the evidence set: Collect system descriptions, process maps, logs of use, data source records and existing GDPR documents so your team can answer each of the six Article 27 elements.
- Facilitating workshops: Run structured sessions with business owners, affected-group representatives where appropriate, and oversight staff, and capture their input as decisions for your team to confirm.
- Setting up the record: Configure self-hosted tools such as CISO Assistant for assessment tracking and framework mapping, XWiki for version-controlled assessment pages, and BookStack for role-based access to the record.
- Drafting template answers: Prepare draft wording for each element for your owners to review, edit and approve.
- Keeping the trail: Maintain version history so changes and approvers are visible over time.
In fixed-scope work, agree in writing which drafts the partner produces, who reviews them, and who signs the final record.
Review of the assessment sits outside your organization. The market surveillance authority receives the notified results and can ask questions about them. Where your organization or a partner engages an independent assessor for readiness or assurance, that assessor gives its own view. Neither can be replaced by your own team signing off its own record as if it were a regulator decision.
- Independent review: Authorities and independent assessors form their own view of whether the assessment is complete and proportionate.
- No self-validation: An internal reviewer can check quality, but an internal sign-off does not count as an authority decision or a third-party report.
- Evidence requests: Expect questions on who was consulted, how risks were chosen and how oversight works in practice.
- Consistency with other records: Reviewers compare the Article 27 notice with the GDPR impact assessment, the Article 26 deployer records and the Annex VIII registration summary where those apply.
- Confirmed scope: Ask the authority or assessor which format and questionnaire version they expect, since the AI Office is developing a template.
Before engaging an assessor, confirm whether the engagement is a readiness review or an assurance opinion, because they lead to different outputs.
Where organizations usually fall short on Article 27
Most gaps in a fundamental rights impact assessment come from treating it as a one-time document rather than a process tied to deployment. The cards below cover the mistakes that recur most often and the concrete action that closes each one. Check each item against your own deployment before the system goes live.
Generic vendor template used as the assessment
A provider's template or a generic questionnaire rarely reflects how your organization actually uses the system. Article 27 asks for a description of your processes, period and frequency of use, and the specific risks in your context. Reuse the provider's assessment only where the use is similar, then fill in your own processes, staff roles and decision points. Ask which parts of the provider's material you may cross-reference, and record where you did so.
First-use timing missed
The assessment must be completed before the first use of the high-risk system, not after go-live or at the next audit cycle. Teams often start a pilot in one department and assume the pilot does not count as use. Map every deployment, including pilots and limited rollouts, to a named owner and a sign-off date that comes before the first decision the system supports. Keep the dated sign-off in the same record as the assessment.
No evidence of affected people
The assessment must identify the categories of people the system affects, such as applicants, policyholders or patients. Many organizations list groups in general terms without showing how they reached that list. Document the data sources used to identify affected groups, the business owners consulted, and any groups excluded and why. Confirm the list still matches the population the system scores or decides about today.
Complaint mechanisms not tied to handling
Article 27 expects the assessment to describe governance and complaint mechanisms, but a published form is not enough if no team processes what arrives. Route complaints about the system into the same ticketing or case tool used for other customer or citizen issues, with an owner, a triage rule and a closure record. Test the route once with a sample complaint and keep the result as evidence that the mechanism works in practice.
No update trigger for changes
The assessment must be updated when elements change, but many organizations set no trigger for updates. A new data source, a new user group, a model change or a new country of use can each alter the risks. Write a short list of change triggers into the assessment, assign a reviewer for each, and require the reviewer to confirm in writing whether the assessment still holds after every change to the system or its use.
GDPR DPIA and FRIA disagree
Where the same system needs a GDPR data protection impact assessment, the two records often describe the same processing differently. The 2026 amendments let deployers cross-reference or include parts of a GDPR DPIA, which makes consistency easier to enforce but also easier to break. Keep one owner for both records, a shared inventory of data flows and risks, and a reconciliation check at each review. Where a finding appears in one record, confirm the other reflects it.
Questions buyers ask about the Article 27 assessment
Does a private company without public service duties need a fundamental rights impact assessment?
Usually not, unless the system falls into one of the listed groups. Article 27(1) covers deployers of Annex III high-risk systems that are bodies governed by public law, private entities providing public services, or deployers of credit scoring and life and health insurance pricing systems (Annex III points 5(b) and 5(c)). A private firm that is none of these and does not run those systems is outside the Article 27 duty. A private lender or insurer is caught by the credit or pricing category even without public-service functions. Critical infrastructure systems are excluded from the assessment. Confirm each system's Annex III classification with counsel, and read the consolidated text of the Act before you rely on this answer.
How much effort does a fundamental rights impact assessment take?
The Act sets no duration or cost, so effort depends on how many systems and use cases you assess and how much process documentation already exists. The assessment must describe your processes, the period and frequency of use, the categories of affected people, the specific risks of harm, the human oversight measures, and the measures if risks materialize, including governance and complaint mechanisms (Article 27(1)(a) to (f)). Effort rises with each additional system, each affected group, and each risk that needs its own mitigation. It falls when an earlier assessment, including the provider's, can be reused in a similar case under Article 27(2), with updates for elements that change. Ask any partner to break its estimate down by system and by element, and confirm the internal hours that business owners, legal and oversight staff will need.
Can we complete a fundamental rights impact assessment in-house?
Yes. The obligation falls on the deployer, and the Act does not require an outside firm to write the assessment or sign it off. Your team needs authority over the use case, the affected people and the oversight design, which usually sits with business owners, legal, and the teams that run the system. External help is most useful for structuring the evidence and keeping it current. As an implementation partner, DeployOpen prepares systems, controls and evidence, and it does not issue assessments or sign-offs. Tools can support the record: CISO Assistant (AGPL-3.0-only) tracks assessments against frameworks, XWiki keeps a version history of every change, and BookStack controls who can edit and read the write-up. The deployer makes the notification to the market surveillance authority using the template, so confirm the format that authority expects.
How long before first use should the assessment be ready?
The assessment must be finished before first use, so plan backward from your first planned deployment. The Act sets no preparation period. As amended in 2026, the high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems, so deployers of those systems plan against that date. Allow time to confirm which systems fall under Article 27, collect process, frequency and affected-group data, design human oversight and complaint routes, complete legal and DPO review, and submit the notification. Any later change to a listed element requires an update under Article 27(2), so schedule a review trigger for changes in use case, population or model. Ask your partner for a schedule tied to your first-use date, and confirm the dates for your own category with counsel.
Can a GDPR DPIA replace the fundamental rights impact assessment?
Not entirely, but the 2026 amendment lets the two documents work together. Under Article 27(4) and (5) as amended in 2026, a deployer may cross-reference or include parts of a GDPR data protection impact assessment. A DPIA under Regulation (EU) 2016/679 covers personal data risks, so it can supply material on data categories, risk analysis and safeguards. It may not cover the other Article 27 elements in full, such as the period and frequency of use, human oversight measures, and governance and complaint mechanisms. Map each of the six elements to a source, whether a DPIA section, an existing policy or new content. The AI Office is to develop a questionnaire template, including an automated tool, so check its status before you choose a format.
What does the assessment need from our team?
It needs named owners from several functions, because the six elements cover how the system is used, who it affects and how people can challenge its outcomes. Typical contributors include the business owner, who defines processes, period and frequency of use; the DPO or privacy lead, who handles data flows and overlap with the DPIA; legal or compliance, who confirms the Annex III classification and the template; the team that runs human oversight, which needs trained staff and clear stop or override paths; and engineering, which supplies logs, access controls and technical safeguards. One person should own the complaint mechanism and the governance record. Confirm the internal hours with your partner before the scope is fixed, because they vary with the number of systems and their users.
What should we ask a partner for in a fixed-scope quote?
Ask for the written scope before any work starts. It should list the systems covered, the reason each is in or out of Article 27, and which of the six elements the partner prepares. Ask what the deliverables are, such as a draft assessment, a completed notification template, and an evidence register that links each statement to a source. Confirm whether the DPIA mapping is included, who reviews and signs off, and that the deployer keeps the decision. Ask how changes to the use case or model are handled after delivery and whether they fall under a retainer. List the client inputs assumed, such as staff interviews, process data and existing DPIAs, and check the exclusions, including legal opinions and authority correspondence. DeployOpen works from fixed scopes, deliverables and timelines agreed in writing and does not publish prices, so compare quotes on the written scope.
How DeployOpen prepares the Article 27 evidence set
DeployOpen prepares the systems, records and documents a deployer needs to complete an Article 27 fundamental rights impact assessment and its notification. The deployer owns the assessment and its conclusions, and the scope of each engagement is agreed in writing before work starts.
How we scope
- Confirm which deployer type applies under Article 27(1) and whether the system is a credit scoring or life and health insurance pricing use.
- Agree in writing which high-risk systems, business processes and affected groups the assessment covers.
- Map the six Article 27(1) elements to named owners, source systems and existing records before any drafting starts.
How we build
- Set up a versioned assessment workspace in a self-hosted wiki so every change to the assessment is recorded.
- Organize the assessment as a control register in a self-hosted compliance platform that tracks evidence, owners and review dates.
- Document human oversight measures, complaint routes and the measures planned if risks materialize, with test records where they exist.
How we hand over
- Deliver the completed assessment with its evidence index, owner sign-off record and change history, in formats the deployer controls.
- Prepare the notification pack for the market surveillance authority, leaving submission and sign-off with the deployer.
- Show the deployer where Article 27(4) and (5) allow cross-referencing to an existing GDPR DPIA, and mark the elements that need a review.
How we support
- Ongoing support and periodic reviews are available as a retainer, so updated elements are reflected when the system or its use changes.
- Re-check the assessment against Article 27(2) when the provider's assessment or the deployer's use changes.
- Confirm with your legal counsel and the relevant authority whether the template or questionnaire published by the AI Office applies to your filing.
