Founder
September 14, 2026
27 min read
An educational technology provider cannot give the YAZEK declaration on behalf of the institution. But it can make it possible for the institution to make a correct declaration, to implement that declaration in practice within the product, and to test whether the declaration remains true as the product changes. This final article in the series proposes turning the expression “YAZEK-ready product” from a marketing slogan into a model design specification usable among provider, product team, and educational institution.
It is no longer surprising to encounter this sentence in an EdTech product’s pitch deck: “Our product is YAZEK compliant.” The sentence looks reassuring; but what legal outcome it denotes is unclear. The Ministry of National Education Ethical Declaration System for Artificial Intelligence Applications is not a mechanism that issues compliance certificates for products or pre-approves tools. According to the Ministry’s current explanation there is also no “list of safe artificial intelligence tools”. The subject of the declaration is not the platform’s commercial name; it is the nature and scope of the concrete artificial intelligence application the teacher will carry out with that platform.[1]
This distinction does not remove the provider from the YAZEK discussion. On the contrary, it defines its role more precisely. If an institution does not know what data the product processes, what it produces, which model or third-party component it works with, what the teacher can change, and how a new version affects previous use, it cannot secure the accuracy of the answers in its ethical declaration. If the product’s interface facilitates behaviour contrary to institutional policy, does not allow important functions to be turned off, or does not produce the records needed at the moment of an incident, even the best-prepared policy finds no counterpart on screen.
For this reason the legitimate and strong promise the provider can make is not “we guarantee legal compliance”. The more accurate promise is:
Our product provides the product capabilities needed for the educational institution to define its concrete use correctly, limit it according to its own rules, operate it under human oversight, prove its outcomes, and reassess when change occurs.
What is called YAZEK readiness in this article is this quality. This expression is not an official MEB status or certificate. It is a design and assurance model proposed to translate YAZEK principles into the product lifecycle.
Previous articles in this series addressed a different gap each: linking the YAZEK declaration to a living institutional compliance system; impact assessment before use; open-future assurance against profiles that trap the student in past data; making the artificial intelligence procurement contract an instrument of visibility and intervention; establishing justified human ownership and effective appeal in grading. At the final stage the task is not to explain these matters again but to derive product requirements from them.
Each legal output built in the series gives the product a consequence question and a counterpart. When the concrete use scenario is taken as the basis, the product must be able to distinguish which module is used for which purpose and target group; the counterpart is scenario identity and separate configuration profile. When impact assessment determines use limits and stop thresholds, the institution’s decision must be implementable within the product; the counterpart is policy controls, feature gates, and stop authority. When the student’s future must not be closed to a single inference, the lifespan, secondary use, and effect of inference must be limitable; the counterpart is purpose separation, expiry, reassessment, and non-algorithmic path. When the contract secures change, audit, and exit rights, these rights must be technically usable; the counterpart is version notification, evidence export, rollback, and portability. When human oversight requires justification, authority, and appeal, the human must truly be able to decide on the product; the counterpart is review surface, original human action, correction, and second-look support.
This mapping is not a simple “legal requirements list”. When product roadmap, institutional policy, and procurement contract are not tied to the same use scenario, three separate realities arise: the institution declares one thing, the contract promises another, and the software permits a third. The real aim of YAZEK readiness is to turn these three realities into one system.
The same product does not have the same level of readiness when a teacher uses it to draft materials in a closed environment, when it is used as a teaching assistant that talks directly to the student, and when it assesses student work. Moreover, the same module can run in two institutions with different data fields, authorities, retention periods, and human oversight rules. A product that offers sufficient evidence in today’s model version may weaken previous assurance tomorrow with a silently added new function.
Readiness is therefore the quality of this relationship:
YAZEK readiness = product capability × concrete use scenario × institutional configuration × current version × continuity of evidence
If one multiplier is missing, a general “compliant” label attached to the product name cannot close the remaining gap. A product with safe defaults can be used for the wrong purpose; an institutional decision taken for the right purpose may lose validity in a new version; a well-configured system may be unauditable after an incident because it does not produce evidence.
At this point the concept of declaration fitness may be proposed. A declaration-fit product is not one that auto-fills the YAZEK form. It is a product that clearly shows the facts the institution will declare, establishes the technical counterpart of the answer given within the product, and makes visible whether that counterpart is broken across the lifecycle. Four capabilities must exist together:
Enabling correct declaration: Providing reliable information on purpose, target group, data, model function, decision effect, and limits.
Operating the declaration: Implementing use limits the institution sets through settings, role, permission, feature gate, and safe defaults.
Proving the declaration: Showing with proportionate records which configuration, model, and human action were valid at which moment.
Keeping the declaration alive: Informing the institution when product or use changes whether previous assessment must be reviewed and, where necessary, safely freezing use.
Without the first capability the declaration becomes guesswork; without the second, a declaration of intent; without the third, a claim that cannot be proven; without the fourth, a photograph that quickly goes stale.
Institutional artificial intelligence policies often use the right verbs: limited, overseen, recorded, stopped when necessary. The task of product design is to ask what counterpart these verbs have on screen and in system architecture. If student data will be used only for a specific purpose is written, which technical separation will prevent off-purpose use? If it is stated that the final decision rests with the teacher, can the teacher accept with one click without seeing, changing, or building their own justification for the suggestion? If a specific function is prohibited, can the institution administrator turn off that function for all users?
Here a principle that may be called control–evidence symmetry is needed:
Every important policy rule must be tied to an implementable control within the product; every important control must be tied to proportionate and accessible evidence showing it works.
If a feature cannot be turned off, an institutional ban is fragile. If a setting is not recorded with version and time information, it cannot be verified later. If a warning is produced without defining who receives it, it is not intervention. If a record cannot be exported in an understandable form by any authorised party, it becomes a data pile rather than accountability.
This approach does not mean “the more logs, the more compliance”. Especially recording children’s behaviour in detail may create a new surveillance risk. Design must respect the difference between evidence needed to audit an event and decision and unnecessary behavioural tracking of the student. The evidence architecture must also be subject to data minimisation, role-based access, retention limits, and secure deletion.
A high-impact artificial intelligence function in education cannot be entrusted to a single safeguard. The warning “output must be checked by the teacher” is insufficient if the interface pushes the teacher toward automatic acceptance. A content filter does not solve who will be informed and how to intervene when harmful output occurs. A notification clause in the contract does not protect the institution retrospectively if the product has already moved to a new model.
YAZEK-ready design must therefore build six layers together.
1. Define: Purpose, target group, data, artificial intelligence role, and prohibited uses are determined at scenario level. If the layer fails, feature gate and administrator alert cover undefined or out-of-scope use. 2. Limit: Safe default, role/permission, data domain, and function restriction are applied. Contrary attempts are made visible with incident record and notification to responsible person. 3. Oversee: The authorised human’s authority to preview, change, reject, and stop is made real. Unusual acceptance patterns, error clusters, and appeals are brought to process review.
4. Evidence: Version, configuration, output, and original human action are recorded in proportion to purpose. If evidence is missing, decision effect is limited or high-impact function is not run. 5. Correct: Error, appeal, and incident outcomes spread to linked records and derivative outputs. In bulk error, suspension and rollback of use are made possible. 6. Renew or exit: Change is classified, retested, institution informed; continuity and data exit are secured. If assurance cannot be maintained, return to previous version, function shutdown, or safe exit from provider is executed.
This architecture does not promise to make error impossible. It sets a more realistic and legally more valuable goal: to make it harder for error to pass through a single control unseen and reach the student as an outcome; and when it does reach, to provide capacity for detection, correction, and learning.
The specification below is not a technical standard published by MEB. It is a model developed to translate expectations in YAZEK, the Ethical Guide for Artificial Intelligence Applications in Education, and MEB’s developer/service provider recommendations into the product lifecycle.[2] Providers can use it in product requirements document and release gate; educational institutions in pre-qualification, pilot, and acceptance test; policymakers as a starting point for a future common assurance scheme.
The unit of evaluation of the specification is not the company or platform as a whole but the combination product + module + version + use scenario + institutional configuration. For each requirement more than a “yes/no” answer is sought: owner of control, scope, test method, evidence produced, known limitation, and review date.
YH-01 — Scenario identity clearly defines for each artificial intelligence function the intended use, target age/group, pedagogical function, data categories, output, and decision effect; states unsupported uses. The acceptance question is whether the institution can show in a single record what it declares independently of product name; evidence produced is version-linked product/system card and scenario passport. YH-02 — Institutional policy control enables the institution to set use rules by module, user role, class/section, data domain, production mode, and decision effect; risky functions can be off by default. The acceptance question is whether institutional decision moves from user recommendation to system behaviour; evidence is configuration summary, authority matrix, and change history. YH-03 — Data and component boundary requires closing unnecessary data fields, separating educational data from secondary uses such as model training/product development, and making sub-provider and model dependencies visible. The acceptance question is whether the institution can audit which data goes to which component and for which purpose; evidence is data flow summary, component register, and retention/deletion verification.
YH-04 — Safe default for children and pedagogy embeds in the product’s default behaviour content safety, accessibility, cognitive load, and interaction limits proportionate to age and function; ties pedagogical benefit to a testable target. The acceptance question is whether the product only blocks harmful content or also protects the quality of the learning relationship; evidence is age/group-based test report, accessibility outcome, and pedagogical validation record. YH-05 — Human control surface enables the authorised person to see input and artificial intelligence output, understand uncertainty, change, reject, add explanation, and stop the system; the interface does not steer toward automatic acceptance. The acceptance question is whether the human truly decides or is merely the final click approving the model result; evidence is human action trail, override test, and authority verification. YH-06 — Notification, explanation, and correction carrier shows artificial intelligence role to the user in age-appropriate form; produces understandable information linked to the outcome; enables transition to the institution’s application/appeal channel and propagation of correction to linked outputs. The acceptance question is whether the student or parent understands not only “artificial intelligence was used” but how it touched their own outcome; evidence is notification samples, decision context summary, and correction propagation record.
YH-07 — Proportionate observability records model/version, active configuration, critical event, artificial intelligence output, and human intervention in proportion to risk; the institution can export these in understandable format. The acceptance question is whether review is possible without confusing the system at the moment of the event with today’s system; evidence is timestamped evidence package, audit export, and access logs. YH-08 — Change impact management classifies change in model, data flow, function, interface, or sub-provider by effect on use scenario; risky change is not activated before required test and institution notification are complete. The acceptance question is whether the new version silently breaks assumptions of the old assessment; evidence is change impact notification, comparative test, and institution decision. YH-09 — Incident, rollback, and exit enables the institution to suspend use, identify and correct erroneous bulk outputs, return to previous safe version/workflow, and export data/evidence in usable format. The acceptance question is whether educational activity and student rights are protected without being locked to the provider when the product does not work safely; evidence is incident file, rollback test, continuity, and exit package.
Not all nine requirements apply at the same intensity in every use. In a teacher tool with no direct student contact, no personal data processing, and no effect on decisions, record and approval layers may be lighter. By contrast, in a function touching grade, level, admission, discipline, guidance, or student profile, basic controls cannot be removed on the ground that “product experience becomes harder”. Proportionality is not eliminating protection but adjusting control intensity according to the error cost of use.
A design error EdTech providers often make is to present the product as if it had a single use purpose. Yet generative content, teaching assistant, learning analytics, and assessment functions can combine in the same interface. A purpose as broad as “artificial intelligence for education” carries neither declaration nor test nor distribution of responsibility.
Every module must therefore carry a scenario identity: purpose, target age and need group, course/learning function, inputs, outputs, place of output in human decision, supported and prohibited uses. The institution must be able to link this identity to its own application and create a configuration profile. Thus the institution’s decision “this tool only produces draft feedback; it does not suggest grades” becomes a technical state in which the grade-suggestion function is off, not a sentence left in the user guide.
This control plane also gives the provider strategic advantage. Instead of forking code for every customer, verifiable risk profiles are offered on the same product. Limits written by the legal team become acceptance criteria for the product manager; institutional policy becomes an administrator setting.
Classic software growth logic may count more interaction, longer use, and richer data collection as success indicators. In an educational product aimed at children these indicators are not value on their own. Design that increases screen time, emotional attachment, or the extent to which the student uses the system to think in their place may raise commercial engagement while weakening educational purpose.
MEB’s recommendations for developers, producers, and service providers bring together data minimisation and privacy by design with design appropriate to children’s cognitive, emotional, and social development, screen time and break functions, content filtering and moderation, pedagogical/ethical tests, and accessibility in the same area of responsibility.[3] This togetherness matters: child safety is not only content moderation; data protection is not only a privacy text. What the product encourages, which behaviour it facilitates, and which data it chooses not to collect at all is a design decision.
As a comparative example, the UK Department for Education’s generative artificial intelligence product safety standards updated in January 2026 require providers to state purpose and target group clearly; support claims with evidence; prioritise child safety and transparency in design; and test new models and versions before release. The standards also recommend direct pedagogical design choices such as offering graduated hints instead of giving the student the full solution directly, seeking genuine student effort, and creating friction or teacher approval before moving to full solution.[4] These are not binding rules under Turkish law; but they are a useful policy example showing that a “safe EdTech product” is not only cybersecurity.
When human oversight is left in an organisation chart and the right of appeal in a contact form, the product may not support them. A screen where the authorised person can change the model suggestion but cannot see the actual student work does not provide genuine review. If a “Reject” button exists but hundreds of outputs are accepted at once by default because of workload, formal control covers de facto determinativeness.
A YAZEK-ready product designs the interface according to the importance of the decision. In high-impact use it can limit bulk automatic acceptance; separate artificial intelligence suggestion from human-added justification; send the decision to mandatory review when uncertainty or data deficiency exists. Explanation presented to student and parent should provide understandable context on inputs used in the concrete outcome, criteria, artificial intelligence’s role, and correction route—not repeat the model’s source code or general product brochure.
Here the product does not replace the appeal authority. Who reviews the application within what period is the institution’s legal and administrative arrangement. The product’s task is not to block the institution from operating this route effectively; it is to preserve the relevant decision moment, export the necessary file, propagate correction to derivative outcomes, and not present the first automatic answer as “second review”.
The security report the provider sends the institution at the start of the year does not on its own show which model and settings were used in a particular class three months later. The product must therefore be able to produce a compliance evidence package for each approved use profile. The package is not a new surveillance pool opening all student data to the provider; it is structured export of proportionate records sufficient to verify specific claims.
The minimum package may consist of:
product, module, model/sub-model, and version identity;
timestamped summary of active use scenario and institutional configuration;
valid roles and permissions and open/closed state of high-impact functions;
scope, date, outcome, known limitations, and validity period of relevant tests;
proportionate record of critical event, alert, and human intervention;
effect of recent changes on scenario and pending institution actions;
where necessary, references enabling link to decision, appeal, and correction file.
This package is not a new policy or contract annex; it is a runtime output showing that they work. Separating it into three access levels—public product card, customer-specific configuration summary, and detailed incident file open only to authorised auditor—can strike a better balance between trade secret and transparency and student privacy.
In artificial intelligence products the classic “version number” alone is insufficient. The provider can change the underlying model, system instruction, content filter, data retention behaviour, or sub-provider without changing the interface. The product may look the same to the user while error pattern, data flow, or effect on decision has changed.
Conversely, tying every bug fix to a new YAZEK declaration is also wrong. YAZEK’s current explanation states that if a new module or feature does not change the scope, instructional purpose, or target audience of the existing application, re-declaration is not required. It is also explained that if scope, educational purpose, artificial intelligence tool used, or target audience do not change for the same application, repeat declaration is not sought.[5]
The provider’s task is not to announce the legal consequence on behalf of the institution but to make visible the facts of change relevant to decision. For this a four-level change classification can be used.
D0 — Technical maintenance is a fix or patch that does not affect scenario assumptions; product-side record and routine test, institution-side informational version record suffice. D1 — Assurance effect is change affecting filter, accuracy, accessibility, or human control; targeted regression test and evidence package update are required; notification to risk owner and acceptance test if needed are expected. D2 — Use effect is meaningful change in data flow, model, output type, decision weight, or supported user group; impact analysis before activation, feature gate, and explicit institution decision are sought; EYZED/policy/contract review and YAZEK update need are assessed by the institution. D3 — Boundary breach is opening prohibited use, loss of assurance, or unacceptable high risk; default block, version freeze or rollback is required; institution goes to non-start/stop use and re-decision path.
In this model the institution is not showered with notifications; change is not silenced either. Timing, content, and required action of notification are tied to the real effect of change. “Significant change” thus ceases to be only an ambiguous expression in the contract and becomes a classification question the product team must answer before release.
An institution’s ability to stop the product, end the relationship with the provider, or return to a workflow without artificial intelligence is not an exceptional crisis scenario but infrastructure of human oversight. “Approval” without rollback authority is in practice dependence on the provider’s roadmap. An institution that cannot obtain decision records in understandable format when use ends, or verify deletion of student data and derived profiles, cannot account for past operations.
Exit must therefore cover educational continuity as much as data portability. When the product closes, how will examination, feedback, or support process continue? Which record stays with the institution, which derivative output is invalidated, which integration key is revoked, how will deletion be proven? These questions must be addressed in the first architectural decision, not after the product goes to market.
Checking boxes on a control list does not on its own show that real use is safe. A stronger method is the assurance file approach. For each product–scenario profile the provider builds this chain:
Claim → assumption it rests on → control applied → test/operational evidence → known limitation → responsible person → validity period
For example the basis of the claim “the teacher gives the final decision” cannot be only a sentence in the terms of use. To the claim must be tied evidence that the teacher can see actual work and model suggestion separately, change the outcome, bulk automatic acceptance is limited, unauthorised role cannot finalise the decision, and these behaviours were verified in acceptance test. If the known limitation is that human action record does not pass to external system in a particular integration, this must be written clearly and the use profile narrowed until remedied.
This method also disciplines marketing language. The UK product safety standards’ approach of tying claims on product effect and capability to solid and transparent evidence is instructive here.[6] For YAZEK the following language distinction should also be preserved.
“MEB-approved artificial intelligence product” may be used only if there is a genuinely given official approval with defined scope and it can be used in full scope. Instead of “YAZEK certified/compliant”, it can be said that specified use scenarios offer product capabilities supporting the institution’s YAZEK assessment and monitoring process. Instead of “guarantees KVKK compliance”, it should be stated that it supports the institution’s data protection measures in the specified data flow and configuration; party roles and legal bases are determined separately. The sentence “human is always in control” should be replaced by explaining in which role, at which moment, with what information and change/stop authority human control exists. Instead of “fully safe and unbiased” claim, test scope, comparison groups, error limits, known risk, and retest date should be published.
MEB’s recommendation to providers on ethical compliance certificates and openness to independent audit does not conflict with this distinction.[3] Independent audit or certificate can be valuable evidence; but it cannot be presented as a product approval given by YAZEK without scope, standard, date, and version reviewed being stated.
YAZEK readiness can also be tracked by maturity level rather than a single pass/fail score.
Level 0 — Promise-focused product has general ethical/compliance statements; use scenario and evidence are unclear; institution cannot tie claim to concrete use. Level 1 — Documented product has defined product card, data flow, tests, and limitations; but institutional policy does not change product behaviour. Level 2 — Configurable product allows institution to set role, data, and function limits; the main gap is that settings and human actions are not sufficiently evidenced as working. Level 3 — Observable and intervenable product has proportionate record, alert, correction, stop, and export working; but new version and incidents do not renew assurance on their own. Level 4 — Lifecycle-managed product ties change impact, regression test, institution re-decision, learning from incident, rollback, and exit in the same system; remaining risk is managed openly in use context.
Maturity level is also not a compliance ruling. It shows how much technical support the product can give the institution’s compliance capacity. A low-impact scenario may be accepted with lighter controls; absence of third or fourth level capabilities for a high-impact decision function may be a reason to stop.
YAZEK today mainly makes visible the ethical governance line between declaration holder and educational institution. The next policy question is how product information on which the declaration rests will be presented in a common and comparable form. Every institution asking the same provider for information in different formats both exhausts school capacity and creates unpredictable demands for small EdTech companies.
The specification proposed here can over time form the core of a common EdTech product assurance scheme. Such a scheme can:
without loading YAZEK with product certification function, standardise minimum provider data fields the declaration holder needs;
establish product–module–version–scenario identity in machine-readable format to match institution inventory with provider version record;
set different evidence levels for low- and high-impact uses;
tie change impact notification to common classes;
enable comparable presentation of independent tests, pilot outcomes, and known limitations;
allow controlled reuse of evidence produced once instead of forcing small providers to fill hundreds of different forms.
Comparative regulation also shows the direction is toward product lifecycle. NIST’s generative artificial intelligence profile recommends that risks may differ at model, application, concrete use, and ecosystem level; and that governance, content provenance, pre-deployment test, and incident notification be addressed together across the lifecycle.[7] The European Union Artificial Intelligence Act provides for quality management, technical documentation, automatic logs, conformity assessment, and corrective action for providers of high-risk systems within its scope; it counts some uses toward access to educational institutions, assessment of learning outcomes, level placement, and monitoring of examination behaviour among high-risk areas.[8] These regulations cannot be transferred assuming they create direct obligations for every EdTech product in Turkey. But they show regulatory direction moving from “declaring ethical principles” to “producing evidence across the product lifecycle”.
The most important benefit of a common scheme is to let legal and product teams work on the same object. The lawyer defines abstract principle and unacceptable outcome; the pedagogue limits educational benefit and development effect; security/data teams build technical controls; the product manager turns these into requirements and release gate; the institution takes configuration of concrete use and residual risk. Disciplines contribute to the same assurance file without crossing into each other’s domain.
YAZEK-ready design does not transfer the educational institution’s responsibility to the provider. The institution determines pedagogical purpose, legal basis, target group, teacher authority, and final use decision. Accuracy of the YAZEK declaration is also the responsibility of the declaration holder and institutional governance.
But the converse also holds: The institution’s ultimate responsibility does not allow the provider to externalise information asymmetry within the product as “customer setting”. Model and sub-provider choice, default data behaviour, test scope, interface creating automation bias, change timing, and technical rollback capacity are in the provider’s control domain.
The right line establishes these two sentences together:
The provider cannot give a compliance decision on behalf of the institution. The institution also cannot meaningfully manage risk the provider did not disclose or did not make technically controllable.
For this reason the place of legal/compliance review in product development is not the day the end-user agreement is written. Use limit when product hypothesis is formed; purpose separation when data architecture is drawn; the human’s real authority when interface is designed; change impact when version is released; future of student and institution records when product is discontinued—all must be decided together.
YAZEK created an important threshold for artificial intelligence governance in education: Before the name of the tool used, the purpose, scope, target group, and effect on the student of the concrete application are asked. This threshold must now be completed on the provider side. Because the institution’s ethical declaration cannot be more accurate than the product’s information and control capacity.
A YAZEK-ready EdTech product is not one that helps fill form fields but one that produces the counterpart within the product of the answer given in the form. It can turn off what the institution prohibits, run what it permits within limits, ensure the human truly intervenes, preserve the moment of incident in proportionate form, correct error through derivative outcomes, and make visible in time when a new version affects the old declaration. If assurance cannot be sustained, it can stop, return, and allow the institution to exit.
At the end of the series the outcome should be not a list of documents but a single governance principle:
Compliance is not a file carried beside the product; it is the architecture of what the product permits, blocks, records, corrects, and refuses to do when necessary.
For EdTech providers the next strategic step is not to prepare a general “we are YAZEK compliant” statement but to run a YAZEK readiness gap analysis for each product–scenario profile, tie YH-01–YH-09 requirements to product roadmap, and collect evidence in an assurance file that lives with the version. For educational institutions the question should shift from “Does this product have artificial intelligence?” to “Does this product make our declaration technically correct, auditable, and reversible?”
A clear and evidenced answer to this question does not only facilitate the YAZEK process. It brings together the provider’s product discipline, the institution’s procurement quality, and the student’s legal safeguards in digital education in the same architecture.
Sources and online explanations were reviewed as of 10 September 2026. The “YAZEK Readiness Product Specification” is an unofficial model proposal developed in this article. The work contains general legal and institutional assessment; for a particular product or use the institution’s status, data flow, contract chain, target group, technical architecture, and legislation in force must be examined separately.
