Do users know when they are communicating with an AI system or receiving AI-generated content?

The AI ​​Act mandates active disclosure at the moment of interaction (Art. 50). It is not sufficient to mention this in terms and conditions or a privacy statement.

Can you demonstrate that AI-assisted decisions are auditable and correctable by an authorized person?

For high-risk systems, the AI Act requires that human oversight be structurally ensured (Art. 14); not as an exception, but as part of the design. Additionally, under GDPR Article 22, there is a prohibition on using solely automated processing as the basis for decisions that significantly affect the individual, such as decisions with legal effects or similarly substantial consequences, unless specific conditions are met.

Has the model been tested for bias regarding protected characteristics such as gender, ethnicity, or age?

Organizations are responsible for the output of their AI, even if bias was not intentionally introduced but arises from training data. Documentation of this testing is required under Art. 9 (risk management) and Art. 10 (data quality) of the AI ​​Act.

Have you determined whether US authorities can demand access to your data under the CLOUD Act?

The scope of the CLOUD Act is determined by who controls the data, not by where the server is located. An EU data center of a US provider does not offer absolute protection. Relevant factors are: the identity of the provider and the extent to which it, as a US legal entity, has actual access to the data, the applicable data processing agreement, and which entity can access the data in practice.

Is it contractually excluded that your business data is used to train or fine-tune the vendor's model?

With public AI APIs, this depends on the specific contractual agreements. Enterprise agreements usually exclude this, while consumer versions often do not. Check the current processing terms; do not assume that protection is standard.

Do you have insight into where your data is processed when making predictions or decisions (inference)?

With most SaaS AI solutions, data is sent to external APIs for processing. This is not prohibited by definition, but it does require a current data processing agreement and, in the case of transfers outside the EEA, appropriate transfer safeguards in accordance with Art. 46 GDPR, such as standard contractual clauses (SCCs) or an adequacy decision.

Are all AI applications that process personal data included in your processing register?

The GDPR requires organizations to keep track of which data is processed, for what purpose, and via which systems. AI tools, including tools adopted informally, fall explicitly under this. An incomplete register is one of the most common findings in GDPR audits.

Is security built into the architecture of your AI systems, and do you have monitoring in place that alerts you in a timely manner if something deviates?

Both are necessary. A secure architecture (such as local inference or ‘compute-to-data’) limits the attack surface. Continuous monitoring detects what architecture alone does not see: behavioral/bias drift, hallucination patterns, and deviations in decisions over time. The AI ​​Act explicitly requires post-market monitoring for high-risk systems (Art. 72). Architecture and monitoring are complementary, not alternative.

Are all relevant AI interactions and decisions logged in a reliable, structured, and auditable manner?

The EU AI Act requires deployers of high-risk systems to retain logs in order to reconstruct incidents and account to regulators (Art. 26(5)). The technical logging capabilities must be built in by the provider (Art. 12). Logs must not only be available but also structured enough to serve as evidence.

For systems that are not classified as high-risk, the AI Act does not impose a legal logging obligation. However, where a system processes personal data in support of decisions, the GDPR requires you to demonstrate compliance (Art. 5(2)) and to provide data subjects with an explanation of automated decision-making upon request (Art. 22). In practice, structured logging is the only way to meet both obligations.