AI Act Fundamental Rights Impact Assessment

Skip key takeaways

Updated August 25, 2026

• The duty is the deployer's, and credit scoring and life and health insurance pricing are named expressly Article 27(1) reaches bodies governed by public law, private entities providing public services and deployers of Annex III point 5(b) and 5(c) systems, which is how a private bank or insurer is caught.
• Profiling closes the derogation that would otherwise let a scoring model out Article 6(3) exempts Annex III systems posing no significant risk of harm on four conditions, but its third subparagraph makes any system performing profiling of natural persons always high risk, and claiming the derogation is itself a documented and registrable act.
• The assessment must contain six specified elements, not a free-form memo Element (d) is the joint one, because it requires the specific risks of harm taking account of the information the provider gives under Article 13, which means the vendor's instructions for use belong in the procurement contract.
• Since July 2026 the FRIA can cross-reference your DPIA instead of merely sitting beside it Regulation (EU) 2026/1744 replaced Article 27(4) and (5), permitting cross-references to or reuse of parts of the data protection impact assessment and obliging the AI Office template to support it. Content citing the old "shall complement" rule predates the amendment.
• The assessment is filed, not shelved, and the Article 46(1) exemption is effectively unavailable to a bank The exemption's grounds are public security, protection of life and health, environmental protection and key industrial and infrastructural assets, none of which covers commercial urgency. For a financial institution the recipient is the national financial supervisor.

Copy takeaways

A bank deploys a credit scoring model. Most of the AI Act work published about that scenario sits on the provider side: the Annex IV technical file, the conformity assessment, the CE marking. Article 27 sits somewhere else entirely. It attaches to the organization that uses the system rather than the one that built it, it names creditworthiness evaluation and life and health insurance pricing in its own text, and what it produces is filed with a supervisor rather than kept on a shelf. For a lender or an insurer that means the duty lands on the same teams that own the model, which is why it belongs in the FinTech development services conversation and not only in the legal one.

In short: the fundamental rights impact assessment is the deployer's duty, not the provider's. Annex III point 5(b) creditworthiness systems and point 5(c) life and health insurance pricing systems are named expressly in Article 27(1), which is how a private bank or insurer is pulled in without being a public body. The assessment has six specified elements rather than a free format. And since Regulation (EU) 2026/1744 replaced paragraphs 4 and 5 on 27 July 2026, it can cross-reference an existing data protection impact assessment or absorb parts of it instead of merely sitting beside one.

Who owes a fundamental rights impact assessment

Article 27 opens on the deployer. The duty arises "Prior to deploying a high-risk AI system referred to in Article 6(2)", and it reaches three classes: "deployers that are bodies governed by public law, or are private entities providing public services, and deployers of high-risk AI systems referred to in points 5 (b) and (c) of Annex III". One exclusion sits inside the same sentence, "with the exception of high-risk AI systems intended to be used in the area listed in point 2 of Annex III", which is the critical infrastructure block. All three passages are in Regulation (EU) 2024/1689, and Article 27(1) was not amended.

A commercial bank is not a body governed by public law, and on any ordinary reading it is not a private entity providing a public service either. It is caught by the third class and only by the third class. That is worth stating plainly because a scoping exercise that stops after the public-body limb concludes the article does not apply, and gets the answer wrong for exactly the two use cases the Regulation cared enough to name in the provision itself.

Why an internally built model has no supplier to point at

Two Article 3 definitions close the obvious exits. A deployer is any person or body using an AI system under its authority, "except where the AI system is used in the course of a personal non-professional activity". That carve-out is the whole of the exclusion. There is no turnover threshold, no headcount threshold and no deployment-volume threshold beneath which the definition stops applying, so a small mortgage broker running a scoring model is a deployer on the same terms as a systemic bank. Separately, "putting into service" is defined as supply "for first use directly to the deployer or for own use in the Union for its intended purpose". Both definitions are in Regulation (EU) 2024/1689, Article 3.

Own use is the load-bearing phrase. A bank whose own data science team builds a scoring model and hands it to the credit function has put that system into service, and is simultaneously its provider and its deployer. There is no vendor to allocate the duty to, no supply contract in which to negotiate it and no external transaction that could have triggered anyone's attention. The absence of a supplier is not the absence of an obligation.

Why creditworthiness and insurance pricing are named

Annex III point 5 sits under the chapeau "Access to and enjoyment of essential private services and essential public services and benefits". Its second limb covers "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud". Its third covers "AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance". Both are quoted from Regulation (EU) 2024/1689, and Annex III point 5 survived the Digital Omnibus untouched.

These are the two limbs Article 27(1) reaches by express cross-reference. Of the eight Annex III areas, only point 5 pulls an ordinary commercial deployer into the assessment duty on the strength of what it does rather than who it is. The logic is visible in the chapeau: a retail lending decision and a life or health underwriting decision were treated as the private-sector equivalent of a decision about access to a public benefit. The duty followed the consequence for the individual, not the sector of the firm.

Where point 5 stops

Two boundaries follow directly from the wording. Fraud detection is carved out of the creditworthiness limb, so a transaction monitoring model is not pulled into point 5(b) by that route. And the insurance limb names life and health insurance only, which leaves motor, property and commercial lines outside point 5(c). Both boundaries are drawn on the purpose for which a system is used rather than on how the model was built or on what the firm is licensed to sell, which is where scoping goes wrong in practice. A model that scores a transaction for fraud and also feeds an affordability decision is inside the creditworthiness limb for the second use whatever it was built for, because the carve-out follows the purpose and not the codebase. The insurance limb runs the same way: a general insurer writing a health add-on prices health risk for that product line and is inside point 5(c) for it, while a life insurer's fleet motor book stays outside. Neither boundary is an exemption from the Regulation. It means only that the Article 27 duty does not attach through this Annex III entry, and the high-risk question still has to be answered on its own terms. Our banking software development teams treat that scoping call as the first deliverable of a lending platform, because the shape of everything downstream depends on which side of point 5 the model lands.

The derogation that does not apply to scoring models

Article 6(3) offers a documented exit from Annex III classification. A listed system "shall not be considered to be high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons", provided it satisfies one of four conditions: performing a narrow procedural task, improving the result of a previously completed human activity, detecting decision-making patterns without replacing the human assessment, or performing a preparatory task to an assessment. The passage is in Regulation (EU) 2024/1689. Read quickly, the preparatory-task limb looks like a live option for a model that merely ranks applications for a human underwriter.

It is not. The third subparagraph of the same paragraph provides that a listed system "shall always be considered to be high-risk where the AI system performs profiling of natural persons". A credit scoring model profiles natural persons by construction, and so does a life or health insurance pricing model. The override carries no materiality qualifier and no test of how the output is consumed, so the argument that works for a document classifier collapses the moment the model scores people. That backstop is Article 6(3), third subparagraph, of Regulation (EU) 2024/1689. Our note on AI Act high risk classification works through the rest of Article 6.

Claiming it is itself a filing

Even where the derogation is arguable, taking it is not a silent internal decision. A provider that considers an Annex III system not high risk "shall document its assessment before that system is placed on the market or put into service", and Article 6(4) attaches the registration obligation in Article 49(2) to that position, again from Regulation (EU) 2024/1689. The cheap route is therefore a documented, registered and reviewable claim rather than an absence of paperwork. For a bank that built its own model, and is consequently the provider as well, that filing is its own to make and its own to defend.

The six things the assessment must contain

Article 27(1) does not describe an approach or a methodology. It specifies an artifact with six required elements, each quoted here from Regulation (EU) 2024/1689.

• (a) "a description of the deployer's processes in which the high-risk AI system will be used in line with its intended purpose" - Regulation (EU) 2024/1689, Article 27(1)
• (b) "a description of the period of time within which, and the frequency with which, each high-risk AI system is intended to be used" - Regulation (EU) 2024/1689, Article 27(1)
• (c) "the categories of natural persons and groups likely to be affected by its use in the specific context" - Regulation (EU) 2024/1689, Article 27(1)
• (d) "the specific risks of harm likely to have an impact on the categories of natural persons or groups of persons identified pursuant to point (c) of this paragraph, taking into account the information given by the provider pursuant to Article 13" - Regulation (EU) 2024/1689, Article 27(1)
• (e) "a description of the implementation of human oversight measures, according to the instructions for use" - Regulation (EU) 2024/1689, Article 27(1)
• (f) "the measures to be taken in the case of the materialisation of those risks, including the arrangements for internal governance and complaint mechanisms" - Regulation (EU) 2024/1689, Article 27(1)

What the list does not ask about

Read as a set, the list describes a deployment rather than a model. Nothing in it asks about architecture, training data lineage or accuracy metrics, which are the provider's material under Chapter III Section 2. Every element asks what happens when this particular organization points this particular system at these particular people, and who catches it when the answer is bad.

What a failing element (d) looks like, and what an adequate one contains

The first three elements are descriptive and a competent team writes them in an afternoon. Element (d) is different in kind, because the text ties it to two things its author does not control: the categories "identified pursuant to point (c) of this paragraph" and "the information given by the provider pursuant to Article 13", both from Regulation (EU) 2024/1689, Article 27(1). That makes it a joint artifact between deployer and provider rather than a piece of internal writing. It is also the element a supervisor reads first, because for a bank or an insurer the file travels to the authority named in Article 74(6), whose staff spend their working lives on model risk.

The version that fails

A failing element (d) is recognizable by what it does not name. It runs to a single paragraph. It says the model may produce inaccurate outcomes for some applicants, that the risk of discriminatory effect is mitigated because protected attributes were excluded from the feature set, and that outcomes are reviewed periodically. Read by someone fluent in model risk, that paragraph asserts three things it has not established.

• Excluding protected attributes is offered as the mitigation, when the ordinary result of excluding them is that postcode, employment tenure, device type and account age carry the same signal. The claim is testable and untested, and no proxy analysis is cited.
• No category from element (c) appears by name, so the harm has no subject. A risk stated for applicants in general cannot be measured against anything, and element (d) is written by cross-reference to be measured against element (c).
• Nothing from the provider is cited, so a reader cannot tell whether the deployer ever received the accuracy figures, the known limitations or the input data specification that Article 13 obliges a provider to supply with the instructions for use. Without those the deployer has no comparator for any performance claim it makes.

Length repairs none of that. A five-page version of the same paragraph fails identically, because the missing ingredient is the join between a named group, a named harm, a measurement and a provider-supplied figure to measure against.

The version that holds

An adequate element (d) is closer to a table than to an essay, and every row is traceable to something a third party can re-derive. Each row carries five fields: the affected category carried over verbatim from element (c), the harm expressed as the decision the applicant receives rather than as a model metric, the measurement that would detect that harm in production, the provider figure or stated limitation the measurement is compared against together with where in the instructions for use it came from, and the residual position once the mitigation is applied. A row for a thin-file applicant segment in a credit scoring deployment reads as the group definition, a decline or a price loading as the harm, an approval-rate and outcome-error comparison against the majority segment as the measurement, the provider's stated performance on that segment or its statement that performance was not established for it as the comparator, and a residual note recording what the deployer accepted and what it routed to human review.

The comparator field is where the joint character of the element becomes concrete, and it is the field that collapses when Article 13 material was never obtained. A provider statement that performance was not established for a segment is a usable input: it is dated, it bounds the claim and it moves the testing burden onto the deployer explicitly. A marketing datasheet is not an input at all, because nothing in it can be false.

What that means for the contract and the acceptance test

Because the comparator has to exist before element (d) can be written, acquiring Article 13 material is a delivery milestone rather than an onboarding courtesy, and two artifacts carry it. The procurement contract names the instructions for use as a deliverable, lists the fields element (d) consumes, requires per-segment performance and known limitations to be either supplied or expressly declared as not established, binds the provider to reissue the document when the model version changes, and grants a right to the underlying evaluation evidence on request. Silence on any of those becomes a gap in the deployer's own file, which the deployer and not the vendor has to explain.

The acceptance test then checks the artifact rather than the promise. It confirms that the instructions for use exist as a versioned document tied to the model version being accepted, that each element (c) category has either a performance figure or an explicit non-establishment statement against it, that the stated intended purpose covers the use the deployer actually plans, and that the limitations section names conditions the deployer can detect from its own production data rather than conditions only the provider could observe. A model that passes on accuracy and fails this test is not ready to deploy, because its deployment cannot be documented.

How the FRIA relates to your DPIA after July 2026

The operative rule is a reuse permission. Where an Article 27 obligation is already met through a data protection impact assessment conducted under Article 35 of Regulation (EU) 2016/679 or Article 27 of Directive (EU) 2016/680, the deployer may "include cross-references to the relevant sections of that data protection impact assessment or include relevant parts thereof in the fundamental rights impact assessment". That is Article 27(4) as replaced by Regulation (EU) 2026/1744. The same instrument replaced Article 27(5), which now requires the AI Office template to "give deployers the possibility to include cross-references to the relevant sections of the data protection impact assessment". The reuse route therefore has to survive contact with the official form rather than depending on a supervisor's tolerance for improvisation.

What changes is assembly, not substance. A firm with a mature DPIA for its scoring model can build the fundamental rights assessment as a shorter document that points into the DPIA for the processing description, the categories of data subjects and the shared risk analysis, then adds what a DPIA has no reason to contain: the deployment processes, the period and frequency of use, the implementation of human oversight and the measures owed if the risks materialise. The two instruments remain separate, with separate legal bases and separate triggers, and neither discharges the other.

What the base text said, and why it still shows up

Before 27 July 2026 the same paragraph provided that the fundamental rights impact assessment "shall complement that data protection impact assessment", from Regulation (EU) 2024/1689. Complement reads as an additive duty, and guidance written against that word tells deployers to produce a freestanding document alongside the DPIA with no reuse permitted. Advice in those terms was written before the amendment, or has not been updated since it, and it now describes a superseded text. Article 26(9) runs the connection in the other direction and was not amended: deployers "use the information provided under Article 13 of this Regulation to comply with their obligation to carry out a data protection impact assessment under Article 35 of Regulation (EU) 2016/679", also from the base Regulation. The AI Act information feeds the GDPR file, and since July 2026 the GDPR file can be lifted back into the AI Act one.

First use, reuse and when the assessment goes stale

Article 27(2) sets the trigger at deployment. "The obligation laid down in paragraph 1 applies to the first use of the high-risk AI system." A deployer may, in similar cases, "rely on previously conducted fundamental rights impact assessments or existing impact assessments carried out by provider". The missing article before provider is how the Official Journal renders that phrase, and it is reproduced here rather than quietly corrected. Both passages are in Regulation (EU) 2024/1689.

The reuse permission is the operationally useful half of the paragraph. A group deploying one pricing model across several entities or product lines does not owe a fresh assessment for each, provided the cases are genuinely similar. It also means a provider's own impact assessment can be relied upon, which gives a vendor something concrete to build and hand over, and gives a buyer something specific to demand during diligence rather than a general assurance of compliance.

What counts as a similar case

Neither similarity nor staleness is defined in the Regulation, and the update duty is where the real exposure sits. If any element listed in paragraph 1 "has changed or is no longer up to date", the deployer "shall take the necessary steps to update the information", from Regulation (EU) 2024/1689, Article 27(2). Read that against the six elements and it becomes a live obligation for any team that ships model changes. A new applicant segment changes element (c). A retrain that shifts the error profile changes element (d). Moving a model from a recommendation to an automatic decline changes element (e). None of those are legal events. They are release notes, which is why the update trigger has to be wired into the change management process rather than into an annual compliance review.

Notifying the market surveillance authority, and how rarely the exemption applies

The completed assessment is filed, not archived. Once it has been performed, the deployer shall "notify the market surveillance authority of its results, submitting the filled-out template referred to in paragraph 5 of this Article as part of the notification". One exemption follows immediately: "In the case referred to in Article 46(1), deployers may be exempt from that obligation to notify." Both are in Regulation (EU) 2024/1689. Most summaries stop at that sentence, which leaves readers with the impression of a general escape valve.

Article 46(1) is not a general escape valve. It lets a market surveillance authority, on a duly justified request, authorize the placing on the market or putting into service of specific high-risk systems "for exceptional reasons of public security or the protection of life and health of persons, environmental protection or the protection of key industrial and infrastructural assets", for a limited period while the conformity assessment procedures are carried out. The authorization issues "only if the market surveillance authority concludes that the high-risk AI system complies with the requirements of Section 2", and for products covered by Section A of Annex I the sectoral derogation route applies instead of this one. All from Regulation (EU) 2024/1689, Article 46.

Commercial urgency is not among those grounds. Neither is a launch date, a competitive window nor a backlog at the supervisor. A bank or an insurer deploying a scoring or pricing model in the normal course of business will not meet any of the four exceptional reasons, so the working assumption should be that the notification duty has no exemption available to it at all. Planning a rollout on the expectation that the assessment can be filed late, or not filed, has no support in the text. This is where compliance and regtech solutions work pays for itself, because the filing has a named recipient, a prescribed format and a moment at which it is owed.

For a bank or insurer the recipient is the financial supervisor

Article 74(6) redirects that notification. For high-risk systems used by financial institutions regulated by Union financial services law, the market surveillance authority is "the relevant national authority responsible for the financial supervision of those institutions under that legislation", but only in so far as the use of the system is "in direct connection with the provision of those financial services". Article 74(7) adds that in appropriate circumstances, and provided coordination is ensured, "another relevant authority may be identified by the Member State" instead. Both in Regulation (EU) 2024/1689, Article 74, which the Digital Omnibus did not amend.

Two things follow. The assessment for a scoring model goes to the same supervisor that already examines the firm's credit risk governance, and will be read by people fluent in model risk rather than by generalists, which raises the standard of what counts as an adequate element (d). And the qualifier at the end of Article 74(6) is doing real work: a system not in direct connection with the regulated financial service does not travel to the prudential supervisor with the rest of the estate, so one firm can owe notifications to two different authorities for two different systems.

Producing the FRIA from artifacts your engineering process already emits

Article 26 already obliges a deployer to do most of the underlying work, and each of those duties emits something the assessment can quote rather than paraphrase. Deployers take technical and organizational measures to use systems "in accordance with the instructions for use accompanying the systems", which is the source of elements (a) and (e). Human oversight is assigned to "natural persons who have the necessary competence, training and authority, as well as the necessary support", which is element (e) in evidence form: named people, dated training records and a documented mandate to override the model. To the extent a deployer controls input data it ensures that "input data is relevant and sufficiently representative in view of the intended purpose", which feeds the risk analysis in element (d). All from Regulation (EU) 2024/1689, Article 26.

None of those outputs is a compliance artifact invented for Article 27. They are deployment documentation, a rota for the oversight function and a data quality report. The assessment becomes an assembly job when those outputs are dated, versioned and addressable, and a three-month project when they live in email threads and a slide deck. Our AI governance framework note covers how to wire the emission points into delivery instead of bolting them on.

Logs are the part regulated firms usually already have

Article 26(6) requires deployers to keep the logs a high-risk system generates, to the extent those logs are under their control, "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months". For financial institutions the same paragraph places them rather than waiving them: such deployers "shall maintain the logs as part of the documentation kept pursuant to the relevant Union financial service law". Both from Regulation (EU) 2024/1689. Six months is a floor rather than the operative test, and our note on the AI Act post-market monitoring plan works out what the appropriate period comes to once a credit outcome horizon is taken into account.

When this obligation actually bites

Material naming 2 August 2026 for Annex III duties was written before the amendment, or has not been updated since it. Regulation (EU) 2026/1744, the Digital Omnibus on AI of 8 July 2026, in force 27 July 2026, replaced point (c) of the third paragraph of Article 113, moving Chapter III Sections 1, 2 and 3, with Article 6(5) carved out, to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III and to 2 August 2028 for those classified under Article 6(1) and Annex I. From Regulation (EU) 2026/1744. The EU AI Act compliance timeline carries the development and the rest of the dates.

For this duty the consequence is narrow and specific. Article 27 sits in Chapter III Section 3, so a deployer of an Annex III point 5 system owes its first assessment from 2 December 2027, while the scoping call that decides whether one is owed at all, and which supervisor receives it, has to be settled well before that date.

What the amendment did not move

Article 27 paragraphs 1, 2 and 3 survive verbatim, as do Annex III point 5, Article 26 and Article 74. The scope of the duty, its six elements, the first-use trigger and the notification route are all unchanged, and only paragraphs 4 and 5 were rewritten. One further change is worth holding in view. The legacy cut-off stopped being a fixed date: Article 111(2) as replaced now reaches operators of high-risk systems placed on the market or put into service "before the date of application of Chapter III referred to in Article 113", which moves with the dates above, while systems intended for use by public authorities still have to comply by 2 August 2030. From Regulation (EU) 2026/1744.

How Pharos Production builds FRIA-ready scoring and pricing platforms

We build FinTech and insurance systems where the model sits inside a regulated decision, so we treat the Article 27 evidence as an output of delivery, not a document written after it. In practice that means the deployment processes and the period and frequency of use are recorded when the system is put into service instead of reconstructed later, oversight is assigned to named people with a recorded mandate, input data relevance is measured against the intended purpose rather than asserted, and log retention is set against the period the Regulation requires.

Because the assessment can now reuse the data protection impact assessment, we build the two as one evidence base with two views rather than two documents that quietly drift apart. Our AI governance and FinTech teams work on that base alongside the build, so the file exists when the model goes live rather than when a supervisor asks for it.

Sources: Regulation (EU) 2024/1689 (AI Act), base Official Journal text, Articles 3, 6, 26, 27, 46 and 74 and Annex III, via Regulation (EU) 2024/1689; Regulation (EU) 2026/1744 (Digital Omnibus on AI) of 8 July 2026, in force 27 July 2026, amending Articles 27, 111 and 113, via Regulation (EU) 2026/1744. Read on 25 August 2026. Provisions replaced by the Digital Omnibus are quoted from the amending Regulation; unamended provisions are quoted from the base text. This article is engineering guidance, not legal advice. Confirm every requirement against the primary text with qualified counsel.

FAQ

Last updated: August 25, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• ★ Featured question. What is a fundamental rights impact assessment under the AI Act?

  Copy link Copies a direct link to this answer to your clipboard.

  It is an assessment of the impact on fundamental rights that use of a high-risk AI system may produce, which certain deployers must perform prior to deploying a system referred to in Article 6(2). It is not free-form.

  Article 27(1) specifies six elements: the deployer's processes, the period and frequency of use, the categories of natural persons and groups likely to be affected, the specific risks of harm to those categories taking account of the provider's Article 13 information, the implementation of human oversight measures and the measures to be taken if those risks materialise including internal governance arrangements and complaint mechanisms.

• Who has to carry one out, the provider or the deployer?

  Copy link Copies a direct link to this answer to your clipboard.

  The deployer. Article 27(1) names bodies governed by public law, private entities providing public services and deployers of high-risk systems referred to in points 5 (b) and (c) of Annex III.

  A private bank or insurer that is neither public nor providing a public service is pulled in by that third class. Where a bank builds the model itself it is both provider and deployer, because putting into service covers supply for own use.

• Does a bank running a credit-scoring model owe a FRIA?

  Copy link Copies a direct link to this answer to your clipboard.

  If the system evaluates the creditworthiness of natural persons or establishes their credit score it falls in Annex III point 5(b), with a carve-out for systems used to detect financial fraud, and Article 27(1) names that point expressly. The Article 6(3) derogation rarely helps, because a system performing profiling of natural persons is always high risk, and a scoring model profiles by construction.

• Does the FRIA replace a data protection impact assessment?

  Copy link Copies a direct link to this answer to your clipboard.

  No. Since Regulation (EU) 2026/1744 replaced Article 27(4) on 27 July 2026, the deployer may include cross-references to the relevant sections of an existing DPIA, or include relevant parts of it, in the fundamental rights impact assessment, and the AI Office template has to offer that possibility. Under the superseded base text the FRIA instead had to complement the DPIA.

  The two remain separate instruments with separate legal bases.

• Do you have to redo it for every deployment?

  Copy link Copies a direct link to this answer to your clipboard.

  The obligation applies to the first use of the high-risk AI system, and in similar cases the deployer may rely on previously conducted fundamental rights impact assessments or existing impact assessments carried out by provider. The exposure is in the update duty rather than the trigger: if any element listed in paragraph 1 has changed or is no longer up to date, the deployer must take the necessary steps to update the information, which a new applicant segment or a retrain can do.

• Who do you send the completed assessment to?

  Copy link Copies a direct link to this answer to your clipboard.

  The deployer notifies the market surveillance authority of the results and submits the filled-out template as part of the notification, with a possible exemption in the case referred to in Article 46(1). That exemption covers only exceptional public security, life and health, environmental or key industrial and infrastructural grounds, so it is not realistically available for ordinary commercial deployment.

  For financial institutions the authority is the national financial supervisor, in so far as use of the system is in direct connection with the provision of those financial services.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.