Founder
September 14, 2026
27 min read
When an artificial intelligence tool begins to be used in the classroom, part of pedagogical decisions is now produced outside the school or university’s own infrastructure. The model may be updated, the sub-processor may change, the purpose of data use may expand, a feature may become paid or the service may end entirely. By contrast the educational institution continues to bear duties to inform the student, ensure human oversight, examine errors and maintain the educational service. For this reason an EdTech contract is not merely a document on price, licence and service level. It is a governance instrument that binds institutional policy to the vendor; supports the ethical declaration with evidence; and makes change visible, intervention possible and exit practicable.
Consider an educational institution that first trials an artificial intelligence-supported writing assistant with a few teachers. During the trial the product gives age-appropriate feedback on student texts; it is stated that data are not used in model training; the teacher can change every suggestion. The institution assesses the use scenario on these conditions, makes necessary disclosures and creates the YAZEK declaration.
After the term begins the provider changes the underlying model. The new version is more fluent; but it produces more errors in Turkish assessment expressions. With the same update the security filter, retention settings and sub-processor list also change. The institution did not learn of the change in advance. It cannot revert to the old version, cannot rerun its own acceptance test and cannot see which model-configuration combination produced a disputed student output. The terms of service give the provider the right unilaterally to change the product.
This scenario is more than an ordinary software fault. The facts on which the ethical declaration rested have changed; the teacher’s oversight capacity has weakened; the records needed for the student’s appeal have become uncertain; and the conditions under which the institution continues the educational service have been tied to the vendor’s product decision. The problem arose not at the end of the contract but at the beginning: The algorithm did not enter the contract sufficiently before it entered the classroom.
The Ministry of National Education Ethical Declaration System for Artificial Intelligence Applications (YAZEK) makes a particular educational use visible in terms of purpose, target audience, data, human oversight and ethical principles. Direct student interaction with artificial intelligence, processing of student data and use of artificial intelligence in assessment, scoring, feedback or grouping are among the main scenarios requiring declaration. YAZEK also explains that there is no Ministry-approved “list of safe tools”; responsibility is addressed through concrete use.[1]
YAZEK’s stated institutional scope covers official schools affiliated with MEB, private educational institutions, science and art centres and public education centres; universities are not within this listed scope. In the model below YAZEK is therefore treated as a direct declaration architecture for institutions within its scope and as a policy reference that higher education institutions can adapt within their own legislation and governance structures.
This structure reveals an important distinction: the teacher who will implement the use creates the declaration; but some information needed for the declaration’s accuracy may exist only with the vendor. Model version, sub-vendor chain, retention architecture, training data, performance tests, security incident, system logs or an approaching product change may not be in the institution’s direct field of observation. The educational institution must nevertheless make a legally and ethically meaningful decision about a technical layer it does not see.
MEB’s approach to artificial intelligence in education also does not leave providers outside the governance space. The Recommendations on Artificial Intelligence Ethics highlight measures for developers and service providers from design onwards: privacy, impact assessment, explainability, human approval, bias testing, age and pedagogical purpose appropriateness, accessibility and secure cooperation with third parties. They also impose on education managers the duty to monitor the vendor’s compliance with legislation and the institution’s ethics-transparency policy.[2]
YAZEK therefore does not replace the contract; but it shows which institutional outcomes the contract must produce. If the ethical declaration says “transparency is provided”, the contract must determine which information and record will be given when; if it says “human oversight exists”, which technical authority can override the system; if it says “data are not used in model training”, the scope, exceptions and verification method of that claim.
In earlier links of this series it was argued that YAZEK is the gateway to a living compliance cycle and that educational impact assessment must be carried out before artificial intelligence use. This article focuses on the next connection: How does the decision the institution gives in its own assessment become a sustainable right against the vendor?
Technology contracts are often negotiated around licence scope, price, availability rate, support period, confidentiality, liability cap and termination clauses. All of these are necessary; but they are insufficient for artificial intelligence-supported educational service. Because the educational institution’s real need is not only to know whom to seek recourse from after harm occurs. It is to know the system before harm, to limit it, test it, catch change and stop it if necessary.
The contract must therefore answer three questions together:
Obligation: Which outcome must the vendor and institution secure?
Evidence: With which record, test or document will that outcome be verified?
Intervention: If the outcome is not secured, which technical and legal authority can the institution use?
For example the sentence “the system will not discriminate” is not a strong safeguard on its own. Which use scenario, which student groups and which error types will be measured; what the acceptable thresholds are; whether the institution can verify with test data; and whether exceeding the threshold leads to limiting, correcting or rolling back the feature must find counterpart in the contract. Similarly a clause that “human oversight is provided” may remain on paper without the teacher’s authority to see, understand, change or reject the output, adequate review time, authority matrix and operation record.
Compensation, liability limit and insurance are the last line of defence of this architecture. Genesis Hukuk’s earlier insurance and institutional liability review addressed which party and policy might bear the financial consequences of algorithmic error.[3] The issue here is different: To turn the contract from a document distributing harm into a governance instrument that prevents harm.
Every cloud service involves cybersecurity, accessibility, data processing and continuity. Artificial intelligence adds five separate layers of uncertainty.
First, output is probabilistic. The same or similar inputs may produce different outcomes; “working” does not mean pedagogically valid or below a given error threshold.
Second, the product is a moving target. When the underlying model, fine-tuning, knowledge source, system instruction, security filter, default setting or user interface changes, the risk profile may change even if the product name stays the same. Interface, algorithm, pricing and access changes that the MEB Teacher Handbook marks as “digital variability” are therefore not only a matter of ease of use but of measurement reliability and educational continuity.[4]
Third, the company with the direct contract often does not produce the whole system. Behind the application provider may be the underlying model developer, cloud infrastructure, content moderation service, analytics tool and support subcontractors. The school’s contractual relationship is with one company; its technical dependency is with a supply chain.
Fourth, the system does not only store data given to the institution; it may derive new data from interactions. Usage telemetry, error labels, student inclination, feedback patterns or risk indicators become a separate governance subject from raw input.
Fifth, there is evidence asymmetry. The vendor can measure the model’s performance and changes; the institution may not access the record needed when it must explain its decision to the student. NIST’s generative artificial intelligence risk profile also recommends assessing third-party risk by context of use, monitoring vendor changes and clarifying in contracts ownership, use, quality, security, secondary use, system change, incident notification, continuity and termination.[5]
These features do not require abandoning a standard cloud contract entirely; they require complementing it with a governance layer specific to artificial intelligence.
In this article we use the expression contractual observability not as an independent right defined in law or an established legal term but as an institutional policy proposal. The concept describes the educational institution’s ability at any point in the service lifecycle to answer the following questions on the basis of evidence:
Which system, model, version and configuration is in use?
For which purpose, target group and data flow was the system authorised?
What was artificial intelligence’s and the human’s effect in a particular student output?
What changed in technical, commercial or data processing conditions?
How were performance, security and equality claims verified?
How can the institution correct error, stop the feature and exit the service?
Observability does not mean the vendor unconditionally opens source code. Source access may not even be necessary for some uses; in some cases it alone does not provide meaningful explanation. The need is to build an evidence and access ladder proportionate to the effect of use. A general system card, intended and prohibited uses and basic performance information may be open to the institution; detailed test reports, architecture and sub-vendor information may be shared under confidentiality; more sensitive records may be reserved for independent auditor or authority access. In some cases trusted third-party verification, secure review environment or summarised technical evidence may be used.
Trade secret is a legitimate interest; but in a high-impact student decision the answer “the product is a black box” does not eliminate the institution’s need for explanation and review. The right solution is not unlimited disclosure or zero visibility but purpose-limited access layers protected by confidentiality.
Principles in YAZEK and institutional artificial intelligence policy can be converted into a contractual control chain as follows.
For transparent and explainable use the contract concretises intended and prohibited use, explanation to be given to the student and individual output trace. Minimum evidence is system and use card, explanation sample and version record; the institution may limit or suspend a function that cannot be explained. Genuine human oversight requires roles and authorities, change/rejection, shutting down automated processing and training. Evidence is authority test, workflow record and user training delivery; the institution may disable automated features and return to manual path. Data and privacy assurance covers data categories, purposes, secondary use, sub-processors, transfer, retention and deletion. Evidence is data flow map, sub-processor register, setting proof and deletion report; the institution may stop processing, pursue data return/deletion, audit and termination.
Pedagogical and technical reliability ties local use criteria, error types, group-based outcomes and robustness to the contract. Evidence is acceptance and regression test and incident and performance report; the institution may reject update, roll back or request correction plan. Management of changes concretises definition of “significant artificial intelligence change”, prior notice and retesting. Evidence is release notes, impact summary and comparative test; the institution may condition approval, preserve old version, suspend or exit. Continuity and reversibility requires data/output portability, transition support, manual alternative and deletion. Evidence is machine-readable export, exit test and deletion certificate; the institution retains transition period, support, termination and substitute solution rights.
This chain is not ready clause text. It is a design map to be concretised with regard to use scenario, institution type, parties’ actual roles, student age, decision effect and procurement method.
So that artificial intelligence governance is not lost among dozens of scattered clauses, five annexes linked to the main contract and speaking to one another may be used. This approach can be adapted both in private educational institution procurement and, to the extent applicable, in the technical specification and contract structure of public procurement.
The first annex defines not the purchased “product” but the permitted educational use. System or module name; direct vendor; underlying model and important components; version/configuration; target age and user group; pedagogical purpose; data categories; weight of output in teacher or administrative decision; intended and expressly prohibited uses appear here.
This passport draws a boundary between the broad capability list in marketing text and the use the institution legally permits. For example if a system is acquired to produce feedback drafts, use of the same module to score students automatically, create disciplinary suspicion or infer psychological tendency does not automatically fall within contract scope. A new use may require new pedagogical and legal assessment even if it does not trigger a new licence fee.
The passport is also the reference point of the declaration file. If version and date links are established between tool, scope, educational purpose and target audience information in the YAZEK form and the contract annex, the institution can later show on which set of facts it made the declaration.
The second annex must not consist only of the sentence “personal data are processed in compliance with KVKK”. Institution data, student/teacher inputs, uploaded content, model outputs, feedback, usage telemetry and profiles derived from these data must be addressed separately. For each dataset purpose, legal role, accessing party, retention period, location, transfer, backup, deletion and secondary use condition must be shown.
Two legal realities matter here. First, the “data controller” or “data processor” label the parties give themselves in the contract does not override actual processing. KVKK’s guide on generative artificial intelligence also assesses roles according to real decision authority over purpose and means of processing throughout a complex and dynamic lifecycle.[6] If the vendor uses data to develop its own product, train the model or produce independent analytics, role analysis must be done on this actual purpose.
Second, use of external resources does not remove the institution’s security and oversight responsibility. Explanations on Article 12 of KVKK draw attention to joint responsibility for security measures where a data processor is involved and the data controller’s duty to carry out necessary audits.[7] Audit right, incident notification, sub-processor flow and verification of deletion are therefore not minor details of the contract.
The cross-border transfer clause cannot be reduced to the statement “servers are in Europe”. The KVKK regime changed in 2024; it establishes a structure of adequacy decisions, appropriate safeguards and exceptional cases. Concrete data flow, party, country, sub-transfers and legal mechanism to be used must be determined separately.[8] When sub-processor or data location changes the institution may need not only to receive email but to object to the change, request an alternative solution or stop the relevant data flow if there is no appropriate safeguard.
On intellectual property this annex should focus on the supply chain rather than reopening the general ownership debate on educational content: Is the vendor authorised to supply the model and components it uses? Under which narrow licence are lesson materials, teacher content and student work uploaded by the institution processed? Can inputs and outputs be used for model training, product development or service to other customers? How are evidence and cooperation provided in third-party rights claims? Since Genesis Hukuk’s earlier reviews of LMS content and distance learning materials addressed ownership and use authority in detail, the new contract layer must ensure those rights are protected in the provider chain.[9]
Classic service level often measures when the system was available. Yet a tool that is 99.9 per cent up may be pedagogically wrong, systematically weak for a particular group or too opaque for the teacher to oversee. Artificial intelligence acceptance is therefore not only a “did the screen open?” test.
The protocol must define which tasks will be tested in which data and language context, error types, false positive/negative cost, Turkish and age-group performance, accessibility, security trials, acceptance thresholds and test repetitions. Pilot with synthetic, anonymised or lawfully controlled data before direct trial on students; independent assessment or the institution’s own validation may be sought for high-impact uses.
A pledge of “zero hallucination”, “complete impartiality” or context-free “99 per cent accuracy” is often not auditable. The right method is to define the test set, measurement method, tolerance, important student groups and consequence of threshold breach. The same assurance standard cannot be used for a writing assistant and a grading system.
Human oversight must also be part of acceptance testing. Can the teacher reject the output? Does the system present the suggestion as final decision? Are there warnings to reduce automation bias? Can the user see which data affected the outcome? On appeal can the incident be reconstructed with the relevant version, input, output and human intervention? The vendor should not be treated as having achieved “human in the loop” without delivering necessary administrator controls, authority roles, usage instructions and training.
One-off acceptance is not indefinite assurance either. Accepted version and configuration should form a baseline; significant updates should trigger repetition of the same critical tests — regression review.
The most distinctive part of an artificial intelligence contract is change control. The vendor must be able to close security vulnerabilities quickly; the institution must not become part of an unannounced mid-term pedagogical experiment. These two needs cannot be balanced by extreme clauses that ban all updates or leave all to the provider’s discretion.
The contract may define significant artificial intelligence change by functional outcome. Underlying model or model provider; fine-tuning and knowledge source; security filter; default system instruction; interface affecting explanation or human approval; purpose of data use; sub-processor and data location; target age; performance threshold; removal of an important feature; change in pricing or access model affecting educational continuity may fall within this scope.
Not every change requires the same procedure. For urgent security update short notice and subsequent evidence may be accepted; for update changing purpose, data flow or effect on student decision prior notice, impact summary, test result and institution approval may be required. Institution rights should also be graduated: request information, additional test, shut down particular function, defer update, revert to previous version, narrow scope of use, correction plan, suspension and as last resort termination.
The internal change threshold must not be confused with YAZEK’s re-declaration threshold. According to YAZEK’s current explanation, a change in platform feature does not alone require re-declaration if it does not change the application’s scope, instructional purpose or target audience. By contrast if tool, scope, purpose or target audience has changed, a new declaration may arise.[10] After receiving contractual notification the institution should first renew its own impact and data assessment; then decide whether the concrete change requires re-declaration under YAZEK. Not every update is a new declaration; but every significant update requires a new institutional look.
Incident management is not only personal data breach. Systematic wrong grade, performance drop in a particular student group, harmful content, failure to produce explanation, unauthorised model change, log loss and prolonged service interruption are separate incident classes. Notification period must be regulated together with nature of incident, scope, affected students, temporary measure, root cause, correction schedule and evidence needed to re-examine student decisions.
An exit clause is not only the sentence “the parties may terminate with thirty days’ notice”. Real exit for the educational institution is: being able to receive data, content, output records and necessary metadata in usable form; being able to move to alternative system or manual process; not interrupting service to the student; and being able to verify that copies with the former provider were deleted.
Therefore machine-readable export format, data dictionary, input/output/decision records to be transferred, transition support, delivery period, cost, temporary continuation of service, deletion schedule from backups and deletion certificate must be defined in advance. For critical institution-specific systems stronger measures such as source code escrow, configuration handover or extended transition service may be assessed separately.
The EU Data Act’s transition approach for data processing services applicable since 12 September 2025 emphasises the customer’s ability to export input and output data and necessary metadata in machine-readable form and removal of contractual and technical transition barriers.[11] This regulation cannot be treated as directly applicable to every Turkish educational procurement; but it shows that exit capability is now one of the central elements of digital market policy, not only goodwill support.
One more element must be added from an educational perspective: pedagogical reversibility. If the system closes, can the teacher continue the same learning outcome by another method? Can a wrong artificial intelligence label be withdrawn and decisions based on it re-examined? Is the student protected from uncontrolled carry-over of a past model score to a new provider? The exit plan must answer these questions as much as technical portability.
In procurement under Public Procurement Law No. 4734 it may be too late for artificial intelligence safeguards to be raised for the first time when the contract is signed. The Law requires technical criteria to appear in the technical specification that is part of the tender documents; to ensure efficiency and functionality, not to have anti-competitive character and to ensure equal opportunity for all bidders. Public Procurement Contracts Law No. 4735 provides that the contract cannot be arranged contrary to tender documents; limits contract changes to cases foreseen in the law; and envisages inspection-acceptance and sanction clauses in the contract structure.[12]
The conclusion is clear: in public education procurement under Laws 4734 and 4735, artificial intelligence ethics, data flow, technical evidence, human oversight, change notification, audit and exit requirements should be designed as far as possible at needs assessment and specification stage. The assumption that a fundamental audit authority or a new acceptance criterion can be added by negotiation after the tender is not reliable.
These requirements can be written by function and evidence rather than describing a particular brand, model or closed technical solution: “error threshold measured by this method in Turkish secondary texts”, “high-impact output rejectable by authorised user”, “notification and regression test within this period for significant model change”, “machine-readable export of institution data”. Thus ethical safeguard and competition principle can meet in the same design.
Not every public body and every procurement is subject to the same regime; exceptions, scope, procurement type and secondary legislation must be examined separately in the concrete case. Method may also differ in private school, foundation university or private sector procurement. But the timing lesson is common: An ethical principle that does not enter procurement criteria may find no bargaining power in the contract.
The European Commission’s Model Contractual Clauses on Artificial Intelligence for the public buyers community, published and updated in March 2025, offer two separate sets for high-risk systems and lighter use scenarios. The explanatory document carries risk management, data governance, technical documentation, records, accuracy metrics, human oversight, corrective action, audit, rights regarding datasets and individual explanation support into the contractual plane. The same document expressly states that model clauses alone are not a complete contract; they must be completed with intellectual property, acceptance, payment, term, applicable law and liability.[13]
This approach is not ready legislation for Turkey. But it shows an important policy direction: artificial intelligence compliance cannot be left to the vendor’s abstract “compliant with legislation” guarantee; information, technical access and cooperation needed for the institution to fulfil its own obligations must flow in the contract.
The EU Artificial Intelligence Act also counts certain educational uses — admission or access to institution, evaluation of learning outcomes, determination of educational level and monitoring of examination behaviour — among high-risk areas in Annex III. For high-risk systems user instructions, purpose, accuracy metrics, foreseeable risk, human oversight, records and change information and supply chain cooperation are prominent headings.[14] As of 9 September 2026 the Commission’s current implementation timeline shows application date of Annex III high-risk rules as 2 December 2027 after the 2026 amendment.[15] These provisions should therefore not be presented to every institution in Turkey today as direct obligations without examining place and role scope and time of application. They are nevertheless valuable for showing the direction in which procurement contracts are evolving in terms of evidence flow.
Similarly the UK Department for Education’s generative artificial intelligence product safety standards updated in January 2026 expect the provider to define intended use and age group, support claims with solid and transparent evidence, keep prompt/response and performance records, test new models and versions before release and for the provider with whom the school contracts directly to give assurance for its own upstream supply chain.[16] These examples, not binding Turkish law, confirm that the educational institution buys not only the final interface but the change and evidence chain behind it.
The easiest place to breach institutional architecture is the “free trial” space where a teacher or department registers for a tool with a personal account. Non-payment does not mean absence of legal relationship and terms of use. On the contrary the institution may become more exposed to unnegotiated online terms, the provider’s unilateral change authority, limited support and records, advertising or product development purposes and sudden charging.
Therefore an acceptable artificial intelligence use policy must also cover shadow procurement. If a tool used with a personal account receives student data, interacts directly with students or affects assessment and evaluation, it cannot be excluded from institution inventory, impact assessment and YAZEK process on the ground that “no budget was used”. Low-risk idea generation or anonymous material draft and high-impact use concerning the student need not be lumped under the same ban; but as risk rises the requirement for institutional account, approved conditions and evidence also rises.
For non-negotiable standard terms Articles 20–25 of the Turkish Code of Obligations on general transaction conditions and especially Article 24 on records granting the drafter unilateral change authority against the other party must be assessed according to the concrete relationship.[17] These provisions are not a shortcut that automatically invalidates every online term. The safest institutional method is to archive which conditions were accepted with version and date, establish priority between main contract and online terms and clarify that change on the provider’s website cannot defeat negotiated safeguards.
The direct provider may say “the underlying model is not ours” or “another company operates the cloud infrastructure”. Even if technically correct this is not a solution for the institution. The educational institution cannot contract separately with every sub-provider. Therefore the direct vendor must reflect obligations within its control area in subcontracts; honestly state information or rights it cannot obtain from upstream provider; and must not market assurance it cannot offer as if it existed.
The contract should at least establish visibility of critical sub-providers and functions, change notification, downstream flow of equivalent data-security obligations, single contact and coordination responsibility in incidents, duty to collect evidence and distribution of consequences arising from sub-provider behaviour. Article 25 of the EU Artificial Intelligence Act’s provision for written agreement on information, technical access and assistance between high-risk system provider and parties supplying artificial intelligence system, tool, service, component or process shows this need is recognised at regulatory level too.[14]
But role and responsibility distribution in the contract does not extinguish the institution’s own duties towards student, parent or authority. Ability to seek recourse from the vendor is one thing; showing due care before decision, ensuring human oversight and examining appeal is another.
Preparing a long contract from scratch for every product is not scalable. A more durable solution is to create an Artificial Intelligence Procurement and Contract Standard in Education within the institution’s policy set. This standard is not a single template but an interconnected decision order:
A short screening form that catches services containing artificial intelligence before purchase,
low, medium and high assurance levels according to effect of use,
control mapping that carries YAZEK and in-house impact assessment decisions into specification and contract,
a modular contract/specification library of five annexes,
an approval matrix showing law, procurement, information security, data protection, academic unit and accessibility roles,
a contract file holding acceptance, version, change, incident and audit evidence,
a change procedure that separates re-assessment and YAZEK re-declaration decisions,
periodic exit and manual continuity test for critical services.
Assurance level should be tied to effect of use, not contract volume. Requesting source code audit for a teacher generating lesson ideas without personal data may be disproportionate. By contrast relying only on a privacy policy link for student admission, grading, discipline, special education support, biometric monitoring or psychological inference is insufficient. A modular standard balances unnecessary burden and insufficient protection.
The first implementation step is not downloading a new template but seeing the current table. Which artificial intelligence features does the institution use under which contracts? Which contracts allow the vendor unilaterally to change model, data or sub-processor? Which YAZEK declaration can be supported with vendor evidence? Which critical service has usable export and manual alternative? A procurement and contract compliance gap analysis on these questions will show which product requires renegotiation, narrowed use, additional test or exit plan as priority.
The educational institution’s goal in artificial intelligence procurement cannot be to obtain a “flawless technology” promise from the seller. Such a promise is not technically realistic and does not remove institutional responsibility. What is legally valuable is to limit what the system is used for, make claims measurable, access necessary evidence, see change in time, protect human decision, correct error and keep exit possible.
YAZEK makes ethical use declarable. Impact assessment determines under which conditions the institution will permit use. The contract ensures those conditions stand when vendor and technology change. If these three layers come apart the institution may have made a correct declaration at term start yet mid-term have to defend outcomes of a system it no longer recognises.
Therefore the algorithm, before it enters the classroom, must enter not only the purchase list but the contract — with its purpose, limit, evidence, change and exit. A good contract does not make the algorithm flawless. It makes it possible for the institution to know it, question it, limit it, stop it and leave it when necessary.
In preparing this work Genesis Hukuk’s Education Technology and Law publications were reviewed together, especially LMS data and supervision, content rights, legal profiling, sensitive data management, ethics governance, artificial intelligence in distance education and insurance-liability reviews. This article does not retell those topics but examines how institutional obligations identified in those works translate into procurement specification, contract, acceptance, change and exit rights.
Editorial note: This article is of a general legal assessment and policy proposal nature. It does not offer ready contract clauses or a one-size-fits-all solution for every institution. In concrete procurement the institution’s status, tender regime, data flow, student group, effect of use, parties’ actual roles, supply chain and current legislation must be examined separately.
