The New Watchdogs of the EU AI Act: Scientific Panel and Advisory Forum Are Live — What GPAI Oversight Means for Turkish Providers

TL;DR — The European Commission has stood up a Scientific Panel of 60 independent experts and a broad Advisory Forum to support enforcement of the EU AI Act. This machinery will shape the systemic-risk classification of general-purpose AI (GPAI) models, evaluation methodologies, and cross-border market surveillance. GPAI obligations have been in force since August 2025, and the AI Office's authority over these models is centralized — it operates independently of delays in member states naming national authorities. Even though the high-risk timeline was pushed to December 2027 by the Digital Omnibus, the GPAI side is "ready and operational." In this piece I explain what the panel does, the technical criteria behind GPAI classification, the concrete exposure of Turkish providers, and a preparation plan that overlaps with KVKK (Turkey's data protection law).

Last week in Istanbul I sat with the legal and engineering teams of a fintech. The engineers were saying "the EU AI Act got delayed, what a relief"; the lawyers, with justified unease, were saying "but something is moving." Both were partly right, and I want this article to clarify exactly that tension.

Yes, obligations for high-risk systems were pushed from 2 August 2026 to 2 December 2027 by the Digital Omnibus compromise. But the EU AI Act is not a single monolithic law; it is an architecture that comes into force layer by layer. And one of the most critical layers of that architecture — oversight of general-purpose models — was not delayed. On the contrary, it is being institutionalized right now. To put enforcement on a scientific footing, the Commission has activated two new bodies: a Scientific Panel of 60 independent world-leading experts and an Advisory Forum bringing together industry, academia, and civil society. Members were appointed for two-year terms.

Don't wave this away as a bureaucratic detail. The bridge between a regulation's text on paper and its impact in the field is exactly this kind of body. Once the panel is in place, abstract articles begin turning into concrete evaluation protocols, threshold values, and audit methodologies. In other words, the answer to "does your AI model carry systemic risk?" will no longer come only from a lawyer's interpretation, but from the technical criteria these experts develop.

The Scientific Panel's mandate is to provide independent scientific advice to the AI Office and national authorities. In practice this turns into several concrete jobs.

First, classifying GPAI models. The law imposes additional obligations on general-purpose models that carry "systemic risk." But when does a model carry systemic risk? In the current framework, one of the basic indicators is the total compute used to train the model (above a certain FLOP threshold). But that is a crude measure, and one of the panel's tasks is to update classification with capability-based, more nuanced criteria — not just "how big," but "what can it do, and where are the dangerous capability jumps."

Second, evaluation methodologies. How do we measure a model's dangerous capabilities (bio-safety, cyber-attack, manipulation)? The panel proposes scientific standards for these evaluations. This is directly relevant to the enterprise AI world too, because the regulatory counterpart of what we today call "red teaming" and "model evaluation" will take shape here.

Third, systemic-risk alerts. The panel can warn the AI Office about models that are not yet classified as systemic risk but are showing warning signs. This is a proactive, not reactive, view of oversight.

Fourth, support for cross-border market surveillance. The EU is a single market; a model placed on the market in one member state circulates in the others. The panel helps ensure the technical consistency of that surveillance.

"

A field observation: regulation of a technology gets serious when the people who understand it best sit down at the oversight table. A 60-strong independent science panel makes the comforting assumption that "the EU doesn't understand and can't keep up" a dangerous one. They are keeping up.

In mid-2026 there is an interesting picture. Member states have still not finished designating national competent authorities. There is a structural readiness deficit that practitioners call the "enforcement gap": even if legal authority activates in August, practical enforcement may lag because member-state infrastructure isn't ready.

But — and this is a very important "but" — this gap does not apply on the GPAI side. Oversight authority over GPAI models is centralized; it sits directly with the AI Office. Whether a member state is ready or not does not affect GPAI obligations. The AI Office is operationally ready.

The practical meaning: if your EU AI Act exposure runs mainly through high-risk use (Annex III: hiring, credit scoring, biometrics, critical infrastructure), the shift to 2027 gives you some breathing room. But if your exposure runs through providing a GPAI model — or substantially modifying one and placing it on the market — you face an oversight counterpart that is operationally ready.

Type of exposure	Main obligation layer	Timeline	Enforcement readiness
High-risk system deployer (Annex III)	Risk management, data governance, human oversight	Deferred to December 2027	Member-state authorities not yet fully ready
GPAI model provider	Transparency, copyright, documentation	In force since August 2025	AI Office centralized, ready
Systemic-risk GPAI provider	+ evaluation, incident reporting, cybersecurity	In force	AI Office + Scientific Panel
Prohibited practice	Full ban	Since February 2025	In force

Turkey is not an EU member, so it's tempting to say "this doesn't bind us." That is the most common — and most expensive — misconception I encounter in the field.

The geographic scope of the EU AI Act, like the GDPR, is based on "effect," not "establishment." You can fall directly within scope in three scenarios.

First, if you supply a product/service to the EU market. If a Turkish software company sells an AI-powered SaaS to a customer in the EU and that system falls into a high-risk use, provider obligations are triggered. "My server is in Turkey" does not change scope.

Second, if the output is used in the EU. If the output your model produces is used inside the EU, you can fall within scope regardless of where you are established. This is critical especially for B2B AI service providers.

Third, through the supply chain. If you supply a component (model, API, data) to an EU customer's high-risk system, your customer will pass part of the obligations to you by contract. So even if the regulation doesn't reach you directly, it extends to you indirectly through commercial contracts.

The GPAI side requires special attention. In Turkey, teams building Turkish-focused open-source or proprietary foundation models are increasing. When these models are placed on the EU market, GPAI transparency obligations — a summary of training data, a copyright policy, technical documentation — kick in. The "we're a small team" excuse is not in the law; the model's nature, not its scale, is decisive.

One of the points I stress most when working with Turkish organizations: don't see the EU AI Act and KVKK as two separate bureaucratic burdens. They overlap heavily, and you can meet both with a single governance discipline.

Data governance is at the heart of both. KVKK's principles of "data minimization," "purpose limitation," and "explicit consent / legal basis" stand on the same ground as the data-governance and quality requirements the EU AI Act asks for in high-risk systems. An organization that documents what data an AI system was trained on, where that data came from, and which legal basis it rests on, feeds both frameworks at once.

Transparency too. KVKK's information obligation and the EU AI Act's transparency obligation to "tell the user they are interacting with AI" face the same direction. A chatbot saying "I am an AI" is correct practice under both KVKK and the AI Act.

The human-oversight principle overlaps with KVKK's provisions on automated decision-making and profiling. Protecting the individual against fully automated decisions with legal effect exists in both frameworks.

"

Practical advice: build a single "AI system inventory." For each system, fill in: purpose, data used and legal basis, risk class (AI Act), link to the KVKK processing record, human-oversight point, model/provider information. This inventory feeds both KVKK logic and AI Act documentation. Don't do the work twice.

The panel's most-debated job will be updating systemic-risk thresholds. Today one of the main metrics is training compute; models above a certain FLOP threshold are treated as potential systemic risk. But that metric is increasingly inadequate, because efficiency is rising: models reaching the same capability with far less compute exist. With distillation and better data, small models approach the capabilities of large ones. So the equation "big = dangerous, small = safe" is breaking down.

Capability jumps are not linear. A model can acquire unexpected new abilities at a certain scale (emergent capabilities). Pure parameter or FLOP counts don't capture these jumps. That's why I expect the panel to move toward capability-based, task-based evaluations: evaluation suites measuring model performance in specific risk areas like dangerous bio-information generation, autonomous cyber-attack, and scaled manipulation. For the enterprise side, this means the "model cards" and evaluation reports you'll demand from providers will become standardized. Start asking your providers for these documents today.

The deferral bought you time; turn that time into systematic preparation rather than panic. A staging that works in the field looks like this.

Months 0–3: Inventory and classification. List all your AI uses (including purchased SaaS — don't forget shadow AI). Tie each to an AI Act risk class and a KVKK processing record. Which are high-risk, which carry GPAI exposure, which touch the EU market? Without this inventory, everything else is guesswork.

Months 3–6: Gap analysis. For your high-risk systems, compare the documents the AI Act requires (risk-management system, data governance, technical documentation, human oversight, logging) against your current state. If you are a GPAI provider, prepare your transparency and copyright documentation.

Months 6–10: Contracts and supply chain. Review your contracts with providers (model, API, data). Add clauses on obligation transfer, audit rights, model-card requests, and incident notification. If EU customers will pass obligations to you, match that to pricing and capacity.

Months 10–16: Operationalization and drills. Build and test your incident-reporting process. Verify with a tabletop drill that your human-oversight points actually work. Run an internal audit; find an independent set of eyes.

Phase	Main output	Owner
0–3 months	AI system inventory + risk classification	CDO / Data governance
3–6 months	Gap-analysis report	Compliance + Engineering
6–10 months	Updated vendor contracts	Legal + Procurement
10–16 months	Incident process + internal audit	Risk + Security

The Scientific Panel is a technical body; the Advisory Forum represents a broader set of stakeholders. Industry, SMEs, civil society, academia, and standards bodies are represented here. The forum's function is to give applied input to the AI Office and the European AI Board — bringing field reality to the table while technical standards, implementation guidance, and templates are being prepared.

Let me explain why this matters with an example. A regulation says "appropriate data governance must be applied for high-risk systems." That sentence alone is almost useless for an engineer. What's useful is the technical standards beneath it: which data-quality metrics, which bias tests, which documentation template. The Advisory Forum exists precisely to keep these standards from being desk products disconnected from the field. I recommend that Turkey's industry associations and technology bodies follow these processes closely and, where possible, open input channels through their EU counterparts; because the standards taking shape today will be your audit criteria tomorrow.

The thing that turns compliance urgency from an abstract "nice to have" into a board-level matter is the scale of penalties. The AI Act's penalty regime was designed to overshadow even the GDPR. Violations involving prohibited practices can trigger fines up to a percentage of global annual turnover or a high fixed ceiling; high-risk and GPAI obligation breaches have graduated but still serious ceilings. The logic is the same as the GDPR's: the penalty must be large enough to genuinely deter, so that compliance becomes a board issue rather than a line item.

Proportionality matters: the regulator watches that penalties are applied proportionately for SMEs and start-ups. But don't slip into the comfort of "we're small, it won't touch us"; proportionality affects the size of the penalty, not the existence of the obligation. Use the penalty not as a threat but as a number that clarifies the investment decision: next to potential fines and reputational loss, the cost of compliance is usually small.

Perhaps the least-discussed but most decisive part of AI Act compliance is documentation. When an audit comes, saying "we do these things" is not enough; you must be able to show it. For high-risk systems you should keep: technical documentation defining the system's purpose, architecture, and limits; data-governance records documenting the source, quality controls, and bias tests of training and test data; process documents showing how the risk-management system works; system logs (who, when, with what input, what output); operational records showing where and how human oversight kicks in; and post-market monitoring results.

Most Turkish organizations don't train the model themselves; they take it from a provider (closed API or open weights). So compliance largely becomes vendor management. When selecting a provider, ask: Do you provide a model card and evaluation report? Do you give the training-data summary the AI Act requires? What assurances do you offer on copyright and data sources? What is your notification process for a security incident? Where do you process the data, and is there a data-residency option? Is your model near the systemic-risk threshold?

A more sustainable path than managing these as one-off projects is to gather them under an AI management system. ISO/IEC 42001 exists exactly for this: a management-system standard for AI — policy, roles and responsibilities, risk assessment, continuous improvement. When an organization builds the 42001 frame, it has already produced most of the risk management and documentation the AI Act asks for, while also feeding KVKK's accountability principle. Instead of three separate compliance efforts, you get one backbone and three branches attached to it.

In short, when that 60-person table in Brussels fills up, what changes is that regulation turns from an abstract threat into a concrete engineering agenda. Turkish organizations that approach this agenda with discipline today will protect their access to the EU market and stay a step ahead on KVKK and sector rules. The secret isn't complicated: know what you do, document it, monitor it, audit it, and fix it. Those five verbs keep you standing no matter which panel makes which decision.