AI Act Cybersecurity Compliance Guide: Secure AI Systems, High-Risk AI and Operational Evidence

SecPoint AI Act Educational Guide banner about secure AI systems, high-risk AI and operational evidence

The EU Artificial Intelligence Act, usually called the AI Act, is becoming one of the most important legal frameworks for organisations that build, deploy, buy or operate AI systems in Europe. It is not only an ethics framework. For high-risk AI systems, it creates concrete obligations for risk management, technical documentation, data governance, logging, transparency, human oversight, accuracy, robustness and cybersecurity.

Educational guide only: This page is provided for general information, awareness and AI security planning. It is not legal advice, an AI Act certification, a CE marking approval, a conformity assessment, or an official regulatory opinion. SecPoint does not issue AI Act certifications, legal approvals or regulatory conformity decisions. Organisations should verify decisions against the official EU text, current Commission implementation guidance, applicable sector rules and qualified legal or conformity-assessment advice.

The purpose of this guide is practical: to help security teams, product teams, compliance officers, ICT providers and management understand where cybersecurity evidence fits into AI Act readiness. Many AI Act discussions focus on bias, transparency, ethics and governance. Those topics are important, but they are not enough. The AI Act also expects high-risk AI systems to be resilient against technical failure, misuse, manipulation, adversarial inputs, unauthorised access and lifecycle security weaknesses.

SecPoint products such as the Penetrator vulnerability scanner and Protector security appliance can support AI Act readiness by helping organisations prepare vulnerability evidence, infrastructure scan profiles, security testing records, network protection evidence and operational documentation. These activities can support a broader compliance programme, but they do not replace the legal obligations of the provider, deployer, importer, distributor, product manufacturer, public authority or financial entity that is responsible for the AI system.

Cybersecurity requirements
Operational evidence model
Penetrator scan profiles
AI Act security checklist
FAQ

What Is the EU AI Act?

The EU AI Act is Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence. It is a horizontal EU regulation, meaning it is designed to apply across many sectors rather than only to one industry. It uses a risk-based model: some AI practices are prohibited, many AI systems remain subject to lighter obligations, and high-risk AI systems are subject to a much more demanding compliance framework.

The AI Act entered into force on 1 August 2024. Its obligations apply progressively, with different dates for prohibited practices, AI literacy, general-purpose AI models, transparency rules and high-risk AI systems. The timeline is important because organisations may have obligations before the full high-risk regime applies. For example, AI literacy and prohibited-practice rules are already relevant, and general-purpose AI obligations started earlier than many high-risk operational duties.

The regulation is not limited to companies headquartered in the EU. It can also affect providers and deployers outside the EU when AI systems or their outputs are placed on the EU market, put into service in the EU, or used in ways that affect people in the EU. For software vendors, cloud providers, AI platform operators and ICT suppliers, the practical trigger is often not the company location but whether the AI system, product or service touches the EU market.

Who Must Care About the AI Act?

The AI Act uses several roles. The most important are providers, deployers, importers, distributors and product manufacturers. A provider is generally the organisation that develops or has an AI system developed and places it on the market or puts it into service under its own name or trademark. A deployer is an organisation that uses an AI system under its authority, except where the use is purely personal and non-professional.

In practice, many companies can have more than one role. A software company that builds an AI screening tool and sells it to employers may be a provider. A company using that tool in recruitment may be a deployer. A reseller importing the tool into the EU may have importer obligations. A manufacturer that integrates AI into a regulated product may face obligations both under the AI Act and under product safety or sectoral conformity rules.

Role	Practical meaning	Why cybersecurity evidence matters
Provider	Builds, has built, places on the market or puts into service an AI system under its name or trademark.	Needs technical documentation, lifecycle controls, risk management, testing records, cybersecurity and post-market monitoring evidence where applicable.
Deployer	Uses an AI system in a professional context under its authority.	Needs safe configuration, human oversight, operational logs, vendor evidence, impact assessment where applicable and controls around actual use.
Importer	Places on the EU market an AI system from a provider established outside the EU.	Needs evidence that provider obligations and documentation are available before market placement.
Distributor	Makes an AI system available in the EU supply chain without being the provider or importer.	Needs traceability, instructions, documentation flow and checks that obvious non-compliance is not ignored.
Product manufacturer	Integrates AI into a regulated product such as machinery, medical devices, toys, lifts or other products covered by EU product legislation.	Needs AI evidence aligned with existing conformity assessment, product safety and cybersecurity evidence.

ICT suppliers should also care even when they are not formally the AI provider. A cloud provider, model-hosting provider, API gateway, identity provider, vulnerability scanning provider, managed security provider or data platform can become part of the customer’s evidence chain. Customers may ask for vulnerability management records, security architecture, access-control evidence, incident notification terms, resilience testing, subprocessor information and audit support.

AI Act Timeline and Current Implementation Dates

The AI Act applies in stages. The original regulation contains staged application dates, and the European Commission’s current implementation material also reflects the Digital Omnibus simplification process, including later dates for certain high-risk AI systems. Because the implementation timeline has been adjusted through political agreement and supporting tools are still developing, organisations should always verify the latest official Commission page before making legal decisions.

Date	What happens	Practical meaning
1 August 2024	The AI Act entered into force.	The legal framework exists, and organisations should start classifying AI systems and planning governance.
2 February 2025	General provisions, AI literacy and prohibited AI practices apply.	Organisations using AI should ensure staff literacy and avoid prohibited practices such as certain manipulative, exploitative, social scoring or unlawful biometric uses.
2 August 2025	Governance rules and obligations for providers of general-purpose AI models apply.	Providers of GPAI models need to follow applicable documentation, transparency, copyright-policy and systemic-risk obligations where relevant.
2 August 2026	Most AI Act rules and transparency obligations become applicable, according to the Commission’s implementation materials.	Organisations should be ready for transparency duties, enforcement architecture and many general obligations.
2 December 2027	The Commission’s current implementation page states that rules for systems used in certain high-risk areas such as biometrics, critical infrastructure, education, employment, migration, asylum and border control will apply from this date, following the AI Omnibus political agreement.	Providers and deployers in these areas should treat the extra time as preparation time, not waiting time.
2 August 2028	The Commission’s current implementation page states that rules for high-risk AI systems integrated into regulated products such as lifts or toys will apply from this date.	Product manufacturers should integrate AI Act evidence into product safety, CE marking and conformity-assessment processes.

Timeline caution: AI Act implementation is an active area. The original regulation, the AI Act Service Desk timeline and the Commission’s Digital Omnibus simplification updates should be read together. This guide uses the Commission’s current public implementation information but does not replace official legal review.

The AI Act Risk Model

The AI Act does not treat every AI tool the same way. A spam filter, a low-risk recommendation tool and a medical decision-support system do not create the same level of risk. The regulation therefore uses categories that are often described as unacceptable risk, high risk, limited or transparency risk, general-purpose AI and minimal risk.

Category	Meaning	Cybersecurity relevance
Prohibited AI practices	AI uses considered unacceptable under Article 5, subject to specific prohibitions.	Security teams should help identify hidden or unauthorised use cases, data flows and biometric or profiling functions that may create prohibited risk.
High-risk AI systems	Systems that fall under Article 6 and Annex III or are safety components/products under listed sector laws.	Highest need for documented cybersecurity, testing, access control, logging, risk treatment and lifecycle evidence.
Transparency-risk AI	Systems such as chatbots, emotion recognition, biometric categorisation or deepfake/content generation where users may need to be informed.	Security teams should ensure identity, logging, labelling, access control and anti-abuse measures around generated content and interactions.
General-purpose AI models	Models that can perform a wide range of tasks and may be integrated into downstream systems.	Cybersecurity evidence may include model access control, abuse prevention, vulnerability handling, model supply-chain controls and documentation for downstream users.
Minimal or lower-risk AI	AI systems outside the above categories.	Still benefit from secure development, vulnerability management, monitoring and responsible governance, even if formal AI Act obligations are lighter.

The key practical step is inventory. An organisation cannot classify AI risk if it does not know which AI systems it uses, where they run, which data they process, which decisions they influence, whether humans rely on them, which vendors supply them, and which interfaces expose them to users, customers or attackers.

High-Risk AI Systems

High-risk AI is the core compliance area for many businesses. An AI system may be high-risk because it is a safety component of a regulated product or because it is used in one of the areas listed in Annex III. Annex III includes areas such as biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration, asylum, border control, administration of justice and democratic processes.

Not every AI system in a company is high-risk. A marketing text assistant used only for drafting internal copy will usually be very different from an AI system used to rank job applicants, evaluate creditworthiness, support medical decisions, allocate essential public benefits or control critical infrastructure. The intended purpose, actual use, affected persons, decision impact and sector matter.

The high-risk classification analysis should be documented. It should not be an informal conversation. A practical classification memo should identify the AI system, provider, deployer, intended purpose, users, affected persons, data categories, decision role, sector, interfaces, vendor dependencies, possible Annex III triggers, possible product-law triggers and the reason why the system is or is not considered high-risk.

Question	Why it matters	Evidence to keep
Is the AI system part of a regulated product or safety component?	This may trigger high-risk classification through product legislation and conformity assessment.	Product description, safety function, product-law mapping, conformity route and technical file references.
Is it used in an Annex III area?	Annex III uses are a major high-risk trigger.	Use-case analysis, department owner, process description and affected-person mapping.
Does it influence decisions about people?	Human impact increases legal and fundamental-rights risk.	Decision workflow, human-review model, appeal process, logs and user instructions.
Does it process sensitive or high-impact data?	Data type affects risk, GDPR overlap and security controls.	Data inventory, lawful basis, data minimisation record, access controls and retention controls.
Can an attacker manipulate inputs, model behaviour or outputs?	Adversarial manipulation is part of AI cybersecurity risk.	Threat model, abuse cases, input validation, monitoring, penetration testing and incident response plan.

Cybersecurity Under the AI Act

Article 15 is the central AI Act provision connecting high-risk AI with cybersecurity. It requires high-risk AI systems to be designed and developed so that they achieve an appropriate level of accuracy, robustness and cybersecurity, and that they perform consistently in those respects throughout their lifecycle. This is not only a launch requirement. It is a lifecycle requirement.

In ordinary software security, a vulnerability may allow an attacker to steal data, take over a server or disrupt service. In AI security, the technical risk can be broader. Attackers may try to poison training data, manipulate prompts, bypass safety controls, extract sensitive data, abuse model APIs, alter ranking outcomes, cause incorrect outputs, exploit insecure plugins, compromise model-hosting infrastructure, or attack the web applications and APIs around the AI system. For high-risk systems, such security failures may also affect health, safety, fundamental rights, employment, credit, education or public services.

A useful AI cybersecurity programme therefore combines normal cybersecurity controls with AI-specific controls. Normal controls include asset management, vulnerability scanning, patching, secure configuration, identity and access management, logging, segmentation, backups and incident response. AI-specific controls include model and dataset lineage, prompt injection testing, input and output monitoring, abuse-case analysis, model drift monitoring, human-oversight procedures, guardrail testing, data poisoning controls and safeguards against unauthorised model changes.

AI security risk	Example	Evidence that supports readiness
Infrastructure vulnerability	Exposed AI API, outdated model-serving server, vulnerable admin panel or weak TLS.	Vulnerability scans, remediation records, configuration hardening, external attack-surface review and patch evidence.
Access-control weakness	Unauthorised user can access model outputs, training data, prompts, logs or admin functions.	Identity design, role mapping, MFA, least-privilege review, access logs and privilege review records.
Prompt or input manipulation	Malicious input causes the AI system to reveal data, ignore policy or perform unintended actions.	Prompt-injection tests, input validation, output filtering, red-team notes and abuse-case documentation.
Data poisoning or dataset integrity issue	Training, fine-tuning or retrieval data is corrupted or manipulated.	Dataset source records, integrity checks, approval workflow, data-quality checks and change logs.
Model or configuration drift	Model behaviour changes after update, retraining, prompt template change or vendor update.	Versioning, benchmark results, change approval, monitoring records and rollback plan.
Third-party AI dependency	External model API, plugin, vector database, cloud service or data provider fails or changes behaviour.	Vendor risk assessment, contract terms, incident notification, resilience plan and exit strategy.

AI Act Requirements for High-Risk Systems

The AI Act requirements for high-risk AI systems should be treated as an integrated control set, not isolated paperwork. Risk management without testing is weak. Technical documentation without logs is hard to verify. Human oversight without training is fragile. Cybersecurity without update control leaves the system exposed throughout its lifecycle.

Requirement area	What it means in practice	Security evidence examples
Risk management	Identify, evaluate, treat and review risks across the AI system lifecycle.	Threat model, risk register, misuse cases, control mapping and residual-risk approval.
Data governance	Control training, validation, testing and operational data quality and relevance.	Data inventory, source approval, integrity checks, access permissions and retention policy.
Technical documentation	Maintain documentation sufficient to assess compliance and understand system operation.	Architecture diagrams, component inventory, interfaces, model versions, security controls and test results.
Record keeping and logs	Enable traceability of operation, events, outputs and incidents where required.	Audit logs, admin logs, API logs, model version logs, security-event logs and retention records.
Transparency and instructions	Give deployers and users the information needed to use the system safely.	Secure configuration guide, user instructions, limitations, human-oversight instructions and incident-contact details.
Human oversight	Design the system so humans can understand, supervise and intervene appropriately.	Role descriptions, escalation paths, override procedures, operator training and review logs.
Accuracy, robustness and cybersecurity	Design and test the system to perform reliably and resist manipulation, errors and attack.	Vulnerability scans, red-team results, penetration tests, robustness tests, monitoring and patch records.
Quality management system	Maintain organisational processes for design, development, testing, release and monitoring.	Secure SDLC, release approvals, supplier controls, incident process, internal audits and management review.
Post-market monitoring	Track performance, incidents, serious risks and system behaviour after deployment.	Monitoring dashboard, issue register, vulnerability handling, customer feedback and corrective-action records.

Operational Evidence: What Auditors and Customers Will Ask For

The AI Act will not be managed only through policy documents. For many organisations, the most difficult part will be evidence. Customers, auditors, notified bodies, market surveillance authorities and internal risk committees will ask practical questions: What AI systems do you use? Which are high-risk? Which data do they process? Who can access them? How are they tested? Which vulnerabilities were found? Which were fixed? What changed in the last release? What happens if the model behaves unexpectedly?

A good evidence model should be simple enough to maintain and strong enough to prove control. The best approach is to create an evidence folder for every AI system and every material release. The folder should not be a dumping ground. It should have a predictable structure so that a third party can understand the system, the risks, the controls and the lifecycle history without interviewing the entire engineering team.

    Suggested AI Act Security Evidence Folder
Classification: AI system description, intended purpose, role mapping, Annex III/product-law analysis and classification decision.
Architecture: diagrams, data flows, model components, APIs, admin interfaces, third-party services and hosting environment.
Risk Management: threat model, AI misuse cases, risk register, residual-risk decisions and control mapping.
Data Governance: data sources, data quality checks, sensitive data controls, retention, access rules and dataset versioning.
Security Testing: vulnerability scans, penetration tests, AI-specific red-team tests, prompt-injection tests and remediation records.
Logging and Monitoring: log design, retention, monitoring alerts, incident classification and evidence of review.
Human Oversight: operator instructions, escalation, override, review process, training records and accountability matrix.
Release Control: model versions, application versions, prompt/template changes, dependency updates, approval notes and rollback plan.
Third-Party Risk: vendors, contracts, cloud services, model APIs, sub-processors, service levels and exit strategy.
Post-Market Monitoring: incidents, complaints, drift indicators, corrective actions, vulnerability handling and management review.

  

The same evidence can also support other frameworks. For financial entities, it may support DORA ICT risk and third-party evidence. For products with digital elements, it may support CRA secure development and vulnerability handling. For critical sectors, it may support NIS2 risk-management controls. For personal data, it may support GDPR security and accountability. The overlap is useful, but only if evidence is structured and reusable.

Penetrator Scan Profiles for AI Act Readiness

SecPoint Penetrator can help organisations prepare technical security evidence around AI systems by scanning the infrastructure, web applications, APIs, network exposure and supporting services that make the AI system available. The goal is not to certify AI Act compliance. The goal is to produce repeatable security evidence that can support an AI Act readiness file.

AI systems are rarely just “a model.” They usually include web portals, API gateways, authentication layers, databases, storage buckets, vector databases, logging systems, monitoring tools, CI/CD pipelines, cloud instances, container platforms, model-serving endpoints and third-party integrations. Weakness in any of these can become an AI system risk.

Suggested profile	What to scan	Evidence value
AI external exposure profile	Public IPs, domains, APIs, model endpoints, admin portals, VPN entry points and remote access services.	Shows whether the AI system has unnecessary or vulnerable internet exposure.
AI web application profile	Web front-end, login pages, user portals, API documentation, upload functions and dashboard interfaces.	Supports evidence for application security, authentication, input handling and secure configuration.
AI internal infrastructure profile	Internal servers, container hosts, databases, vector stores, message brokers, file shares and management interfaces.	Helps document internal technical risk and segmentation needs.
AI release validation profile	Targeted scans after a new AI application, API gateway, model-serving component or platform update.	Creates release evidence showing that security checks were performed before or after deployment.
AI third-party dependency profile	Vendor-exposed portals, supplier-hosted endpoints and integration APIs within the agreed scan scope.	Supports vendor-risk evidence and helps customers ask better supplier questions.
AI incident follow-up profile	Systems involved in an incident, suspected exposed services, patched systems and restored components.	Supports incident remediation and post-incident assurance.

A scan profile should be tied to an evidence objective. Scanning everything without a reason creates noise. For AI Act readiness, useful objectives include: prove that public exposure is controlled, prove that critical vulnerabilities are fixed, prove that administrative interfaces are protected, prove that release changes did not introduce obvious weaknesses, and prove that third-party components are reviewed at reasonable intervals.

Protector and Network Resilience Around AI Systems

AI systems need network protection like any other business-critical system. In many deployments, the AI model may be hosted in a cloud environment, but the business workflow depends on local users, integrations, APIs, identity systems, data sources, firewalls and routing. Network misconfiguration can expose a model, leak data, allow lateral movement or make human oversight impossible during an incident.

SecPoint Protector can support AI Act readiness by helping organisations protect network boundaries, segment sensitive systems, control access, enforce security policy and create operational logs that support evidence. This is particularly relevant where AI is used in critical business functions, public services, finance, education, employment, manufacturing, healthcare support or other environments where disruption could have serious consequences.

Control area	AI Act readiness value	Evidence example
Segmentation	Limits the impact of compromise and separates AI services from general user networks.	Network diagram, firewall rules, zone definitions and access-review records.
Access control	Helps ensure only authorised systems and users can reach AI admin functions and data stores.	Policy export, authentication rules, admin access list and change log.
Logging	Supports incident investigation, operational monitoring and accountability.	Firewall logs, blocked traffic records, administrative action logs and incident timeline.
Availability protection	Supports continuity where AI systems are part of important business processes.	Resilience plan, backup route, failover notes and incident-recovery evidence.
Policy enforcement	Reduces uncontrolled data movement and unauthorised integrations.	Configuration baseline, policy exceptions and management approval records.

AI Act, CRA, DORA, NIS2 and GDPR: How They Connect

The AI Act does not exist in isolation. Many organisations will need to manage it together with other EU digital rules. The key is to avoid building five separate evidence systems. Instead, create one evidence model that can support multiple obligations.

Framework	Main focus	Connection to AI cybersecurity evidence
AI Act	Risk-based AI governance, high-risk AI requirements, transparency and GPAI obligations.	Needs cybersecurity, robustness, logging, risk management and lifecycle documentation for high-risk AI.
CRA	Cybersecurity for products with digital elements placed on the EU market.	May apply where AI functionality is embedded in a software or hardware product with digital elements.
DORA	Digital operational resilience for the financial sector.	Financial entities using AI need ICT risk, third-party, testing, incident and resilience evidence.
NIS2	Cybersecurity risk management for essential and important entities.	AI systems supporting essential services should be included in risk management, incident handling and supplier controls.
GDPR	Personal data protection, security, accountability and data-subject rights.	AI systems processing personal data need lawful basis, security, minimisation, access control, transparency and data-protection evidence.

The overlap can be an advantage. A vulnerability scan of an AI API may support AI Act cybersecurity, DORA resilience testing, NIS2 technical controls, CRA vulnerability management and GDPR security of processing. A good incident log may support multiple reporting and accountability obligations. A well-maintained vendor-risk file may support AI Act supply-chain oversight and DORA third-party ICT risk at the same time.

AI Act Cybersecurity Readiness Checklist

Area	Question	Status
Inventory	Do we have a complete list of AI systems, models, AI-enabled products and AI vendor services?	Required starting point
Classification	Have we documented whether each AI system is prohibited, high-risk, transparency-risk, GPAI-related or lower-risk?	Core evidence
Ownership	Have we identified provider, deployer, importer, distributor and product-manufacturer roles?	Core governance
Architecture	Do we have diagrams showing model, application, data, API, hosting and third-party dependencies?	Technical file
Threat model	Have we considered data poisoning, prompt injection, model extraction, unauthorised access, API abuse and infrastructure compromise?	Security readiness
Vulnerability scanning	Are AI portals, APIs, hosts, containers and supporting services scanned on a defined schedule?	Penetrator evidence
Access control	Are admin rights, model access, logs, datasets and deployment pipelines protected by least privilege?	Security baseline
Logging	Can we trace important events, admin actions, system errors, security alerts and model/version changes?	Audit support
Human oversight	Can a trained human understand, supervise, override or escalate AI-supported decisions where required?	Operational control
Release control	Do model, prompt, dataset, application and infrastructure changes go through documented approval?	Lifecycle control
Incident response	Do we know how to respond if an AI system is manipulated, compromised, produces harmful output or exposes data?	Resilience
Third-party risk	Do contracts and vendor files cover AI model APIs, cloud platforms, hosting, incident notification and exit strategy?	Supplier evidence

Vendor Questionnaire: Questions Customers May Ask

As the AI Act becomes operational, customers will ask vendors more detailed questions. Many of these questions will not be limited to the legal classification of the AI system. They will also ask how the vendor secures the infrastructure, handles vulnerabilities, manages updates and supports evidence.

Customer question	Good answer should include
Do you use AI in the product or service?	Clear description of AI functionality, whether it is core or supporting, and whether customer data is used.
Have you classified the AI system under the AI Act?	Documented classification rationale, role mapping and confirmation that legal classification is reviewed when use changes.
How do you secure the AI system?	Architecture controls, access management, vulnerability scanning, logging, monitoring, incident response and release control.
How do you test for AI-specific abuse?	Prompt-injection testing, misuse cases, red teaming, data-integrity checks, output monitoring and human review where applicable.
How do you manage third-party AI services?	Vendor list, contract controls, data-processing terms, incident notification, service levels, subprocessor information and exit plan.
Can you provide evidence?	Security reports, scan summaries, technical documentation extracts, control descriptions, incident process and support-period information.

What SecPoint Can Help With

SecPoint can help organisations build practical cybersecurity evidence around AI systems. This is useful for internal governance, customer assurance, procurement, risk committees and compliance preparation. The value is not a claim that a scan equals compliance. The value is that repeatable security evidence makes compliance discussions more concrete.

SecPoint capability	How it supports AI Act readiness	Important limitation
Penetrator vulnerability scanning	Helps identify vulnerabilities in AI-related infrastructure, web applications, APIs and supporting services.	Does not decide legal classification and does not certify AI Act compliance.
Penetrator reporting	Produces evidence that can be saved in an AI system security evidence folder.	Reports must be interpreted, remediated and linked to risk management.
Protector security appliance	Supports network protection, segmentation, access control and operational logging around AI services.	Network controls do not replace AI governance, data governance or human oversight.
Dark web and exposure awareness	Can support broader cyber-risk awareness around leaked credentials or exposed assets that may affect AI systems.	Must be combined with identity controls and incident response.
Evidence-oriented security workflow	Helps turn technical controls into records that customers, auditors and management can understand.	Legal obligations remain with the responsible organisation and its advisers.

Implementation Plan: First 90 Days

AI Act readiness can feel large, but the first steps are manageable. The goal of the first 90 days is not to finish every legal requirement. The goal is to create visibility, identify high-risk candidates, start evidence collection and close obvious security gaps.

Phase	Action	Output
Days 1-15	Create an AI inventory covering internal tools, customer-facing products, vendor AI services and experimental deployments.	AI system register with owners and business purpose.
Days 16-30	Classify systems by risk category and identify possible Annex III, product-law, transparency or GPAI triggers.	Classification memo and priority list.
Days 31-45	Map architecture, data flows, access controls and third-party dependencies for priority AI systems.	Architecture and data-flow evidence pack.
Days 46-60	Create Penetrator scan profiles for exposed AI portals, APIs and infrastructure. Review critical vulnerabilities and fix priorities.	Security scan reports and remediation plan.
Days 61-75	Build the evidence folder and connect technical findings to risk management, release control and incident response.	AI system evidence folder with repeatable structure.
Days 76-90	Run management review and define ongoing cadence for scans, vendor review, classification updates and incident exercises.	AI Act cybersecurity readiness roadmap.

Common Mistakes

The first mistake is assuming that AI Act readiness is only a legal project. Legal analysis is necessary, but high-risk AI obligations require engineering, security, operations, data governance, product management and human oversight. A lawyer can help interpret the regulation, but the evidence must come from real systems and real controls.

The second mistake is treating AI as a single tool. Modern AI deployments are systems of systems. A model may be safe in isolation but risky when connected to a customer database, ticketing system, HR platform, payment system, industrial control process or public service workflow. Security review must include the surrounding application and infrastructure.

The third mistake is forgetting updates. AI systems change through model upgrades, prompt changes, retrieval data changes, user feedback, vendor API changes, dependency patches and infrastructure changes. AI Act evidence must therefore be maintained across the lifecycle. A one-time assessment will quickly become stale.

The fourth mistake is producing evidence that nobody can read. A raw vulnerability report may be useful for engineers, but management and compliance teams need a summary showing scope, severity, remediation, residual risk and next action. Evidence should be technical enough to be credible and structured enough to support decisions.

FAQ

Does every AI system need AI Act certification?

No. The AI Act uses a risk-based approach. Many AI systems are not high-risk and do not require the same level of conformity assessment. High-risk systems have the most demanding obligations. The correct starting point is classification, not assuming that every AI tool has the same compliance route.

Does SecPoint certify AI Act compliance?

No. SecPoint does not issue AI Act certifications, legal approvals, conformity decisions or CE marking approvals. SecPoint can support cybersecurity readiness and evidence through vulnerability scanning, reporting, network protection and operational security controls.

Is cybersecurity really part of the AI Act?

Yes. Article 15 specifically includes cybersecurity together with accuracy and robustness for high-risk AI systems. Cybersecurity also supports other AI Act requirements, including risk management, logging, post-market monitoring and quality management.

Can Penetrator scan an AI model itself?

Penetrator is primarily useful for the surrounding technical environment: hosts, web applications, APIs, exposed services, network infrastructure and supporting systems. AI-specific model testing, such as bias testing or model-behaviour evaluation, requires additional methods and domain expertise. The strongest approach combines infrastructure scanning with AI-specific testing.

What should a small company do first?

Start with an AI inventory, classify obvious high-risk candidates, document owners and intended purposes, secure exposed systems, create repeatable scan profiles, and build a simple evidence folder. Small companies should avoid creating a large paper framework before they know which AI systems actually exist and which ones create legal or operational risk.

How often should AI security evidence be updated?

Evidence should be updated when the AI system changes materially, when vulnerabilities are found or fixed, when vendors change, when data sources change, when the model or prompt logic changes, and at defined periodic intervals. For high-risk systems, lifecycle evidence is more valuable than a one-time static report.

Conclusion

The AI Act will push many organisations to treat AI as a governed, documented and security-controlled system rather than an experimental feature. For high-risk AI, cybersecurity is not optional. It is part of the system’s reliability, robustness, accountability and lifecycle control.

The most practical way to start is to create an AI inventory, classify systems, map architecture and data flows, identify exposed services, scan for vulnerabilities, protect networks, document releases, monitor changes and keep evidence. SecPoint Penetrator and Protector can support the technical security side of this work, especially where organisations need repeatable vulnerability and network-security evidence. They do not replace legal analysis, conformity assessment or regulatory decisions, but they help make AI Act readiness measurable and operational.