AI BCF Maturity Assessment: a free AI governance self-assessment

The AI BCF Maturity Assessment is a free AI governance self-assessment that shows how many baseline controls your organization has in place.

It takes about 5 minutes. You answer one question per control, and the result is a readiness snapshot of where your organization stands against the AI Baseline Control Framework (AI BCF): below baseline, baseline met, or baseline plus Tier II met.

Use it as a practical checklist of next steps. It is self-assessed: it is not an audit or a certification, and it is not legal advice.

Your answers stay in your browser: they are saved locally and in the page address (after the #), so anyone you send that link to can see them. There is no login, no email and no server storage. Privacy statement.

The three levels

Answer one question per control

Govern

GV.1

Baseline
Has your organization documented its position on AI, including the goals and limits for its use?

A short written position on AI that is easy to find and has been communicated to the whole organization. It can be part of an existing policy document.

Control text

Why

For artificial intelligence to be adopted effectively in an organization, there must be an organization wide policy and understanding of how the organization views AI in the first place. Without a stated position, departments and teams may decide independently. One team might restrict AI while other staff don't consistently know what data is and isn't allowed to be processed by AI. From this initial decision, the rest of AI policies will flow.

How

A concise document works better than a large manual that employees won't read. The best policy is one that is easy to remember and to find. It may be added onto existing policy documents; but ensure it is communicated clearly to the whole organization when the organization's position on AI is formulated.

Read control GV.1

GV.2

Baseline
Is a named person or team responsible for AI, and do staff know who it is?

A department, team or person is named and documented as responsible for AI and as the point of contact for questions and concerns.

Control text

Why

As AI is used by many different departments in different workflows and types of work, it becomes widely incorporated into the daily business. This may lead to a situation in which AI is unowned. As a result, there may be no clear accountability or department/person who can be reached for clarification, questions or expertise.

How

The organization should name a known department/team/individual as responsible for AI deployment and management within the organization and as the point of contact for questions and concerns. Typically this will be a well-known department or individual with an existing role, although some larger organizations may choose to appoint a person with AI as their sole responsibility.

Read control GV.2

GV.3

Baseline
Have staff who use AI been trained on its responsible, safe and effective use, and is that recorded?

Staff know what is and isn't allowed and how AI output is verified, for example through onboarding or an annual session, and attendance or acknowledgment of the policy is recorded.

Control text

Why

As a result of misinformation and/or misunderstanding of core AI mechanics, organizations may misjudge the risks of AI systems. Such misjudgment can lead to overly stringent rules concerning AI use, or to a lack of critical evaluation of AI output. Article 4 of the EU AI Act establishes AI literacy as an obligation for every organization using AI.

How

Employees must be informed on what is and isn't allowed, and how AI output is verified. The informing training material should be integrated into the onboarding process. For existing employees, an annual session (in which AI might be only a part) that integrates internal feedback on AI use is an excellent way of raising awareness. Acknowledgment of written policy is also sufficient. Ensure that attendance or acknowledgment is recorded.

Read control GV.3

GV.4

Baseline
Are AI risks part of your risk management process, and reviewed at least once a year?

AI risks are in your existing risk register and are reviewed within your normal risk process, at least yearly.

Control text

Why

AI systems present unique risks, such as hallucinated or incorrect output that is presented as fact, third-party AI systems training on organizational data, and insufficient access control. In order to effectively manage such risk, it must first be identified and documented.

How

AI risks should be added to existing risk registers and reviewed as part of the organization's existing risk management process. Organizations should review these risks every year at the least.

Read control GV.4

Comply

CM.1

Baseline
Do you know which laws and regulations apply to your use of AI, and are they documented?

An inventory of applicable laws and regulations exists, is reviewed at least yearly, and notes the date of the last review.

Control text

Why

AI use is subject to both well-known regulations such as the GDPR and more recent regulations such as the EU AI Act, which bans certain AI practices outright. Obligations differ depending on whether the organization is purely a deployer or supplier/developer of AI systems.

How

An inventory of laws and regulations applicable to AI should be integrated into existing registers. Ensure that the inventory of laws and regulations (and the dates that specific clauses go into effect if applicable) is updated annually and that the last review date is noted.

Read control CM.1

CM.2

Baseline
Do you mark AI-generated content and AI interactions as AI when they are published or used externally?

AI-generated content and AI chatbots or other external AI interactions are visibly or audibly marked as AI. Choose “Not applicable” if you publish no AI-generated content and have no external AI systems.

Control text

Why

The EU AI Act requires AI-generated content that is published externally to be marked as such. Interactive AI systems such as chatbots must also be marked as such if they are available externally. Non-AI generated content with minor AI edits (translation, grammar, etc.) are exempt.

How

Departments tasked with external communication (marketing, recruitment, etc.) and those deploying external AI systems such as chatbots, should be trained on their obligations to mark AI-generated content and systems as such. Markings should be visible or audible.

Read control CM.2

CM.3

Trigger
Does AI play a part in decisions about hiring, firing, promotion, pay, access to services or benefits?

Answer Yes if AI supports or informs these decisions about people. If you are unsure, answer Yes to see what the control asks.

Control text

Applies when: AI is used in decisions about hiring, firing, promotion, pay, access to services or benefits.

Why

The EU AI Act obliges organizations using AI systems in processes classified as high-risk to retain logs, conduct human oversight and inform affected individuals. These obligations apply from 2 December 2027.

How

AI and decision-related logs, such as chats and prompts, should be retained for at least six months. Oversight should be documented and assigned to a person with the authority to overrule decisions made with AI. Affected individuals or organizations must be informed that AI is used, and may request an explanation of decisions made with it. Organizations must also follow the provider's instructions for use, monitor the system and report serious incidents to the provider.

Read control CM.3

Register

RG.1

Baseline
Do you have a register of the AI systems in use, with the provider and the data each may process?

Each AI system is listed with its name, provider and the kinds of data it may process (stated once if all systems follow the same rules). Unapproved “shadow AI” that is found is logged too.

Control text

Why

AI enters organizations in many ways; it can be procured, employees can sign up for AI tooling directly, it can be integrated into existing tools by suppliers, etc. This may lead to a situation in which AI tools are used without the organization's approval, bypassing security and privacy requirements in place. If multiple rules regarding what data may enter which AI are in place, the absence of a central register may lead to confusion and questions.

How

Registers of AI systems should contain each system's name, provider, and what kinds of data may be processed in this system (if all AI systems follow the same rules, this can be stated once). The register should ideally be integrated into existing software/IT registers and be updated as part of the organization's existing IT inventory processes. Unapproved AI systems ('Shadow AI') found within the organization should be logged alongside unapproved platforms or software ('Shadow IT').

Read control RG.1

RG.4

Baseline
Does your offboarding process remove the access and accounts of AI systems that are no longer used, and update the register?

When an AI system is retired, your regular offboarding process removes its access and accounts, and the AI register is updated.

Control text

Why

AI systems connected to internal mailboxes, calendars or file stores may retain their access after trials or subscriptions expire, presenting an access risk. Organizational data supplied to the provider may also remain with the provider, unless a deletion request is made.

How

AI system decommissioning should follow the organization's existing offboarding process. After offboarding, the register must be updated. To prevent future training on data if terms change, the organization should request that the provider deletes or returns all organizational data.

Read control RG.4

RG.5

Baseline
Do your supplier privacy assessments check whether your data may be used to train AI models?

When you assess a new or existing supplier's privacy, you check whether your data may be used as training data. When AI features are added to software you already use, known AI risks (such as incorrect output and inherited access) are considered too.

Control text

Why

AI functionality is regularly added to existing products and platforms, which remain covered by the existing processing agreements. Often no reassessment is triggered, and organizational data may then be processed by an AI model or used to train it. Processing agreements and privacy statements are subject to change.

How

Privacy assessments of existing and new suppliers should include whether organizational data may be used as training data for AI models. Known risks inherent to LLM's and other AI systems (see GV.4), such as incorrect output and access inherited from users (see AC.1), should also be considered when AI functionality is added to existing software.

Read control RG.5

Access

AC.1

Baseline
Before an AI system inherits users' access rights (for example Copilot), do you review those access rights?

Before an AI tool that uses a person's existing access rights is connected to your data, the access rights on that data are reviewed. Choose “Not applicable” if you use no AI that inherits user access.

Control text

Why

Most AI systems that can, among other things, search and return organizational data do so under the access rights of the user querying them. Excessive permissions that were previously unexploited become easily discoverable (potentially unintentionally) as the AI system may search within all files the user has access to.

How

Before an AI system that inherits its access rights from a user or existing permission set is connected to organizational data, the access rights on that data are reviewed. This process should be integrated into existing access review processes and be triggered upon the procurement of new inheritance-based AI systems or when such functionality is added to existing systems.

Read control AC.1

AC.2

Trigger
Do you use AI systems (agents, scripts or automations) that access systems or data with their own credentials, such as service accounts, API keys or app registrations?

Credentials that belong to the AI system itself, not to a person.

Control text

Applies when: The organization has deployed AI systems (agents, scripts or automations) that access systems or data with their own credentials (such as service accounts, API keys or app registrations).

Why

Non-human identities, and identity more broadly, are a significant and increasing part of an organization's digital attack surface. AI systems' access rights should be scrutinized and reviewed at least as much as those of human accounts. With no documented scope, the access cannot be reviewed or reduced.

How

AI systems using their own credentials should be given a dedicated identity, separate from any human account. The scope of the AI system's credentials should be documented (which systems and data it can reach, and whether it can read or write). These identities should be managed through the organization's existing identity and access management processes (see AC.4).

Read control AC.2

AC.3

Trigger
Do you use AI systems that can act without human approval?

Systems that can take actions or make decisions without a person approving each one.

Control text

Applies when: The organization has deployed AI systems (agents, scripts or automations) that can act autonomously.

Why

AI systems that act or make decisions cannot be held accountable. Accountability of actions or choices made by AI systems, and responsibility for the AI system, must therefore always be transferred to an individual or team.

How

For deployed systems that can act autonomously, an individual or team/department is named as owner. The owner is responsible for the actions or decisions made by the AI system, and for its operation. The organization should also document which actions the system may take autonomously, without human approval.

Read control AC.3

Tier II: extra depth (optional)

Tier II controls go beyond the baseline. You can skip this section: your result then shows “Tier II not assessed”.

RG.2

Tier II
For each AI use set up for a specific task (agent, script, workflow), are its purpose and what it does recorded?

Your register (see RG.1) records each AI use's purpose, what it does, what it connects to and what data it sends where.

Control text

Why

AI systems that are embedded in processes (scripts, workflows, agents) often operate independently of their creator, and may continue to do so after that person leaves. If the provider and logic are not logged, this important information may be lost and the AI system cannot properly be assessed on compliance with security/privacy controls and (changed) regulations.

How

For each listed AI use (as understood here: an AI system set up for a specific task, such as an agent, script, workflow or dedicated tool), its purpose should be included in the register (see RG.1), along with what the system does, what it connects to and what data it sends where.

Read control RG.2

RG.3

Tier II
For each such AI use, did you weigh proportionality, and also evaluate simpler alternatives (non-AI or smaller models) and document them?

For each AI use you recorded which alternatives you assessed, with a short reason why they were not chosen.

Control text

Why

Large general-purpose large language models (LLMs) are frequently applied to narrow tasks. Smaller, lesser-known models or non-LLM tools are often faster, cheaper, more accurate and less resource intensive than LLMs on such tasks.

How

For listed AI uses (see RG.2), record which alternatives were assessed, along with a short reasoning on why they were not selected.

Read control RG.3

AC.4

Tier II
Are AI access rights granted through your access control model (roles or policies), instead of directly?

AI identities get access through your existing access control policy (role-, attribute- or policy-based), not through direct one-off grants.

Control text

Why

As with human identities, it is much easier to manage, review, and adjust access that is granted through defined roles or permission sets. Integrating AI identities into the organization's existing access control policy keeps AI systems' access manageable and clear.

How

Access should be granted to AI identities through the organization's existing access control policy (this may be role-based, attribute-based or policy-based) instead of directly. All AI identity access control should be part of the organization's access control processes.

Read control AC.4

TR.1

Tier II
Do you measure AI effectiveness with KPIs, including the time spent checking and fixing output?

KPIs compare the AI system with working without it, including the time spent checking and fixing output, set-up time and total cost.

Control text

Why

AI systems are almost always adopted with the expectation that they will increase productivity, output, and automation of repetitive tasks. However, such benefits are rarely tracked and measured. Without such measurements, the actual benefits of deployed AI systems are hard to gauge against the costs of these systems.

How

The organization should formulate KPIs that compare the AI system against the situation in which it is not used. Such measurements should include the time spent checking and fixing AI output. Time spent setting up and fine-tuning the AI system should also be considered. Measurements should include the total cost of the AI system (or the percentage of purchased usage/tokens).

Read control TR.1

TR.2

Tier II
Do you collect and review internal feedback on AI use?

Feedback is collected through existing channels (meetings, chat, e-mail, forms), reviewed by the responsible person or team, and outcomes are shared internally.

Control text

Why

Feedback from employees who use AI systems can provide information on AI benefit and usage that KPIs cannot. These employees see where output is unreliable, where it saves time, and where it may need a specific approach. If the organization does not collect this feedback, it misses the information on which it can better act with regard to AI policy or procurement.

How

The organization should collect such feedback through the existing communication channels, such as meetings, chats, e-mail, or feedback forms. An annual session (see GV.3) may be a good moment to collect feedback. Feedback should be collected by and go to the responsible person or team/department (see GV.2). Outcomes should be shared internally.

Read control TR.2

TR.3

Tier II
Can staff report AI errors easily, and are those reviewed in the AI risk review?

There is a simple way to report AI errors, staff are encouraged to use it, errors are logged and communicated, and they feed into your AI risk review (see GV.4).

Control text

Why

AI output can be factually incorrect, miss critical context or hallucinate details. Most such errors do not need to be recorded, yet errors that appear in business-critical documents or processes can show the organization where AI systems fail in practice. Patterns become clear after collecting such errors and can act as powerful feedback to the organization and a reminder to employees to always check AI output or decisions.

How

The organization should facilitate a simple way to report AI errors, and should encourage employees to share errors and other negative feedback with the responsible person or team/department (see GV.2), or in a dedicated chat channel. This feedback should be considered as part of the AI risk review (see GV.4).

Read control TR.3