# Kulular Teknoloji, English corpus

## The Approval Button You Call Human Oversight Probably Does Not Work

Source: https://kulular.com.tr/en/writing/ai-oversight

The sentence I hear most often when AI governance comes up is this: "There's human approval, the decision isn't left to the machine."
When I hear it, I have one question. What's your approval rate?
There's usually no answer, because nobody measures it. Where it is measured, the figure is typically above ninety-eight per cent. The reviewer overrides the model roughly once in fifty decisions. Calling that human oversight is formally correct and functionally wrong. The system is making the decision; the human is only signing it.
Why the approval button stops working
The cause isn't bad faith. It's design.
Show a person three hundred recommendations a day and ask them to approve each one, and they will automate themselves within weeks. If the model's accuracy is high, this happens faster, because the reviewer is usually right on the few occasions they do reject, and they stop trusting their own judgement.
This is a documented phenomenon called automation bias: the better a system performs, the weaker human oversight of it becomes. Any oversight design has to take that into account from the start.
Three conditions for oversight to be real
For oversight to be functional, three things have to hold together.
The reviewer has to be able to see the basis for the recommendation. If the inputs the model relied on aren't shown, the person can only judge the outcome, and judging the outcome properly means deciding the case from scratch. That makes oversight impossible in practice.
Rejecting has to cost nothing extra. A user who has to fill in a form, write a justification and get a manager's sign-off every time they reject a recommendation will stop rejecting. The rejection path has to be at least as easy as the approval path.
A rejection has to lead somewhere. If rejected recommendations are logged and nobody looks at them, the reviewer notices and disengages over time. Feeding rejected cases back into improving the model keeps oversight alive.
There is no oversight you don't measure
Even once those three conditions are in place, measurement is still needed.
At minimum, three indicators should be tracked: the override rate, the average time spent per decision, and how often an overridden recommendation later turns out to have been correct. If time per decision has dropped to a matter of seconds, oversight isn't happening. The same conclusion follows if the override rate is close to zero.
Very few organisations can answer these questions when asked in an audit. Yet they aren't hard to measure — they come out of data the system already produces.
The right to challenge shapes the architecture
The relevant provision of Article 11 of Turkish Law No. 6698 gives a person the right to object where a result adverse to them arises solely from analysis by automated systems.
The technical consequence is direct. When a challenge comes in, you have to be able to show how the decision was reached. If you can't show it, you can't defend it.
The architectural rule that follows is this: a model that produces no rationale cannot be used in a flow that produces a result about a person. That has to be written in as a constraint on model choice from the outset. Bolting on explainability afterwards is not possible in most architectures.
Keeping a log isn't enough — you have to log the right thing
An audit trail is usually understood as keeping a log, but what the log contains is what decides its value.
For a decision to be reviewable later, five things need to be recorded together: the data that went into the system, the model's version, the output produced, the rationale the output rests on, and the human's final decision. Kept in separate systems, these five can't be matched up afterwards. If the model version isn't recorded, there is no way to answer, months later, "what was the model saying at that point in time?"
Failing to record the model version is the single gap I see most often in practice. The model gets updated, and old decisions get explained by reference to the new one — and it doesn't hold up.
The difference between confident and uncertain has to be shown
One last point. A system should show, in a way the user can tell apart, when it is producing output with low confidence versus high confidence.
Without that distinction, the user trusts everything equally and gets no warning exactly where an error is most likely. Yet a model's own uncertainty is usually measurable. Surfacing that measurement in the interface is the cheapest, most effective improvement you can make to oversight.
If I had to pick one thing to do on an AI project today, this is what I'd pick.

## Most Software Disputes Come Down to One Missing Clause

Source: https://kulular.com.tr/en/writing/software-development-contracts

When a software dispute file lands on a desk, the parties are usually arguing about one thing: does the software work or not.
The reason that argument can't be settled is not technical. The contract never defined what "works" means. With no acceptance criterion, the developer says it was delivered, the client says it wasn't received, and each is right by their own measure.
This single gap is the common thread running through most of the software disputes I've seen.
How to write an acceptance clause that actually works
Acceptance is the moment that triggers the legal consequences of delivery — including when the warranty period for defects starts running. An undefined acceptance date means an undefined end date for liability too.
A working acceptance clause covers: the list of acceptance tests, the environment they run in, who runs them, the objection period, and a provision that acceptance is deemed to have occurred if no objection is raised within that period.
The item most often left out is the test environment. Software that runs on the developer's machine may not run in the client's environment, and at that point responsibility becomes a matter for argument. Define the environment in the contract and the argument doesn't arise.
Tying acceptance to satisfaction is the worst option of all. Acceptance conditioned on "the client's satisfaction" creates an open-ended obligation, and the developer's job never actually ends.
Intellectual-property rights don't transfer on their own
The second common mistake is an assumption about ownership. Clients tend to think that paying for the work makes them the owner of the code. That's not the legal position.
Computer programs are protected as works under Law No. 5846, and unless otherwise agreed, the economic rights stay with the author. Any transfer needs to be set out expressly, made in writing, and list the transferred rights one by one. A general statement like "all rights are transferred" is open to dispute.
Beyond that, three categories need to be kept separate. Code written specifically for the client is usually transferred. The developer's pre-existing components are usually licensed rather than transferred, with the scope and duration of the licence written separately. Open-source components are subject to their own licences, and a list of what's used should be attached to the contract.
When these three aren't kept separate, this is what happens: the client believes it owns all the code, the developer keeps using its own library in another project, and the problem only surfaces once a dispute is already under way.
A contract with no change-management process doesn't survive contact with the project
However well the scope is written, change requests come in during the project. If the contract doesn't say how those requests are handled, every request turns into a negotiation.
A working provision answers five questions. Who does a request go to, and in what form? Who assesses the impact, and within how many days? How are price and schedule impact calculated? Whose sign-off approves it? What happens to a request that isn't approved?
Answer those five and a change stops being a crisis and becomes a process.
Becoming a data processor can happen without anyone noticing
Where a developer has access to a client's personal data, they become a data processor within the meaning of Law No. 6698. That status is often acquired without either party realising it.
The most common route is using real data in a test environment. A copy of the production database gets pulled into staging, developers work with it, and from that point a data-processing relationship exists. If the contract says nothing about it, the relationship runs with no legal basis.
The cleanest fix is never to create that situation at all. Testing with masked or synthetic data is not technically difficult and largely removes the risk. Where access to real data is genuinely necessary, the subject matter, duration and purpose of the processing, the developer's obligation to act only on instruction, use of sub-processors, security measures, and return or deletion of the data at the end of the contract all need to be set out in writing.
Maintenance is a separate contract
Finally, maintenance and support. This is a separate undertaking from development and should be treated separately.
What needs to be written down is not response time but fault classification. Without a definition of which fault falls into which class, every issue gets raised as top priority. Once classes are defined, response and resolution times can be set separately for each.
There's also a measurement question. A service-level commitment that can't be measured has no teeth when it's breached. The contract needs to say how measurement happens and whose records it's based on.
Who should draft this
Every one of these clauses needs law and engineering to decide together. A lawyer can't write acceptance criteria alone, because they don't know what's actually testable. An engineer can't write the IP transfer alone either.
A party that goes into contract negotiation without a technical team ends up agreeing to terms that turn out to be unworkable. An unworkable term behaves, once a dispute arises, as if it had never been written at all.

## If Your Cloud Provider Is Abroad, You Are Already Transferring Data

Source: https://kulular.com.tr/en/writing/cross-border-data-transfers

Ask an organisation "do you transfer data abroad?" and the answer is usually no. Ask which services they use, and a list appears: cloud hosting, email, customer support software, an analytics tool, a payment provider, a backup service.
Most of the services on that list don't have their servers in Türkiye. The real answer was yes, and the organisation didn't know it.
The misunderstanding comes from the word "transfer" itself, which suggests a deliberate act — taking a file and sending it. But holding data on a system abroad, or having it processed there, is a transfer too. No separate act of sending is required.
Seeing where a transfer actually begins
Article 9 of Turkish Law No. 6698 governs transfers abroad. The difficulty in practice isn't the provision itself — it's working out when a transfer has actually occurred.
All three of the following give rise to a transfer: data hosted on a server abroad; a team abroad able to access the system for support purposes; and data being processed abroad with the result sent back. The third is the one most often missed. If you use a text-analysis service and that service is based abroad, the text you send is processed there. Getting the result back doesn't mean no transfer took place.
Our own site has exactly this feature. The free-text field on the home page sends the text entered into it to a provider abroad for analysis. That's why our Data Protection Notice has a section devoted to it, and a visitor can browse the entire rest of the site without ever using that field. Making sure that no transfer occurs at all when the feature isn't used was as much a design decision as the feature itself.
The missing column in the inventory
Most data inventories list category, purpose and retention period. The missing column is: which country does this data physically sit in?
Add that column and the picture changes. Some of the data an organisation assumed was sitting in its own data centre turns out to be abroad. Backups are the most commonly missed item, because the backup service is usually a separate provider and nobody checks where it's located.
When building the inventory, ask the provider directly. If the contract makes a commitment about data residency, get it in writing. If it doesn't, the provider can change the arrangement unilaterally and you won't find out.
The sub-processor chain
The second layer is even less visible. The provider you use may itself rely on other providers for its own infrastructure.
You use a customer-support tool; that tool runs on a cloud provider; it uses a separate service for search; it connects to a third for sending notifications. Your data travels through the whole chain.
You can't fully control that chain, but you can make it visible. The contract should require notice of sub-processor use and give a right to object to a change. Most enterprise providers already offer this — it just has to be asked for.
What to do
The first step is to build a service inventory: the name of every external service used, what it's used for, which categories of personal data it can access, and where its servers are.
Once that table exists, there are three options: replace the service with an alternative hosted in Türkiye, move to the provider's Turkish region if it has one, or put the transfer on a proper legal footing using one of the mechanisms the law provides.
All three carry a cost, and the right choice depends on the nature of the work. But choosing none of them — that is, not noticing the situation at all — is the most expensive option, because it also means your data protection notice is giving inaccurate information, and a single gap ends up breaching two obligations at once.
The rules in this area continue to develop, and Board decisions periodically redraw the framework. Check the current position before choosing a transfer mechanism.

## Where the Seventy-Two Hours Actually Go, Hour by Hour

Source: https://kulular.com.tr/en/writing/data-breach-notification

An alert lands on an organisation's desk on a Monday morning: unusual access has been detected on a server. From that moment, the seventy-two-hour clock starts running.
Seventy-two hours sounds like a lot of time. What follows is an hour-by-hour account of where it actually goes, because without seeing that breakdown it's hard to understand why breach preparation has to happen months before a breach, not during one.
The first eight hours: is this actually a breach
The first task is working out whether the alert is real. It could be a false positive, a maintenance operation, or a misconfigured permission.
At this stage, the technical team goes through logs. If the logs aren't good enough — and in most organisations they aren't — this drags on. Without knowing which account accessed which table from which address, no further step can be taken.
The first critical point is this: if you don't keep logs, the clock starts running out here, and that time is never recovered.
The next twenty-four hours: which data was affected
Once it's established that this is a breach, one question follows: what personal data was on that server?
An organisation with an up-to-date inventory answers this in ten minutes. One without tries to work it out by examining the database schema — checking table names, pulling sample records, asking developers. That alone can easily take a full day.
The second half of the question is harder. What's in the backups? Is there a copy that was exported for a report? Was a sample loaded into a test environment? If the answers aren't written down anywhere, they end up being guessed — and a notification based on guesswork ends up needing to be corrected later.
The next twelve hours: how many people are affected
Once scope is established, a number has to be produced: how many data subjects, which categories of data, which geographies.
A common mistake here is rounding the figure. Saying "approximately ten thousand people" won't get a notification rejected, but a materially different real figure turning up later damages the credibility of the organisation's account. If a precise figure can't be produced, it's better to say so, and say why, than to guess.
The remaining time: preparing and submitting the notification
The notification to the Board needs to cover when and how the breach occurred, which categories of data were affected, its likely consequences, and the measures taken and planned.
Writing that from a blank page uses up whatever time is left. An organisation with a ready template fills it in within half an hour. Who is authorised to sign it also needs to be settled in advance — if that argument starts at this stage, there isn't time for it.
Notifying the individuals affected is a separate task. It's done as soon as reasonably possible once the affected people have been identified; where direct contact isn't possible, another suitable method is used. The language matters here. A message buried in technical detail stops the person understanding what they actually need to do.
What the plan actually needs to contain
The lesson from the timeline above is this: an incident response plan is only as good as what it has already thought through before the incident happens.
It needs a clear allocation of roles: who scopes the incident, who decides it's a breach, who signs the notification. A plan that depends on one person collapses the day that person is on leave.
It needs a defined threshold: what counts as a breach has to be written down in advance, otherwise that argument happens inside the seventy-two hours.
It needs an evidence-preservation rule. The first instinct is often to wipe the affected systems, which makes proper investigation impossible. The plan should say explicitly that logs are preserved untouched.
It needs communication templates ready to go, for both the Board and the affected individuals.
Nothing ends when the notification is sent
Notification isn't the end of the obligation. The Board assesses whether the technical and organisational measures taken were adequate.
A repeat breach at the same organisation reads as evidence that those measures weren't good enough. That's why the corrective action taken after a breach needs to be recorded and its effect measured. The sentence "necessary measures have been taken" is not, on its own, evidence of anything.
The one thing worth doing today
The single highest-value thing you can do before a breach happens is build the inventory with physical location attached: which database, which table, which field, which backup holds which data.
If that table exists, roughly the first thirty hours of the seventy-two are effectively recovered. If it doesn't, no matter how well the plan is written, the time won't be enough.

## What an Auditor Checks First in a Data Protection Notice

Source: https://kulular.com.tr/en/writing/writing-a-privacy-notice

When I review an organisation's data protection notice, the first thing I do isn't read it. It's take the data categories the notice lists and compare them against the database schema.
That comparison produces almost the same result nearly every time: fields exist that the notice doesn't mention. Sometimes the reverse happens too — categories listed in the notice that the system never actually collects. Both point to the same underlying problem: the notice was drawn from a template, not from a proper check of the facts.
The duty is not to produce a document
Article 10 of Law No. 6698 requires the controller, when collecting personal data, to disclose certain things: its identity, the purpose of processing, the recipients data will be transferred to and why, the method of collection and the legal basis, and the rights set out in Article 11.
The operative verb here is "disclose." The document is a vehicle; the duty is to give accurate information. A notice that gives inaccurate information is worse than having no notice at all, because the organisation has now made a statement that doesn't match reality.
That's why drafting the notice has to come after the inventory, not before. An organisation with an inventory writes the notice in a day. One without writes it without knowing what it's actually writing about.
The five mistakes I see most often
I've been seeing the same mistakes for years, and none of them come from a lack of legal knowledge.
Merging the notice and consent into a single checkbox. The user ticks "I have read and agree" and is deemed both to have been informed and to have given consent. A notice is a disclosure, not something to be accepted. Merging the two undermines consent's character as a separate declaration of will.
Showing the notice after the transaction is already complete. The form is submitted, and a link to the notice then appears on a thank-you page. By that point the data has already been collected.
Forcing a single notice to fit every process. Recruitment, customer contact, supplier relationships and website visits all get folded into one document. The result is a general notice that accurately describes none of them.
Not stating the legal basis, or listing all of them at once. A phrase like "under the conditions set out in Articles 5 and 6" states no legal basis at all. Whichever ground a given instance of processing actually relies on should be the one that's written down.
Not stating the retention period. The Communiqué expects this to be included in the information given to the data subject, and without it the data subject has no way to learn how long their data will be kept.
How the notice should be structured
A good notice is written process by process. It doesn't start with "our company processes your personal data" — it starts with "when you fill in the contact form, the following data is processed."
A four-column table for each process makes this much easier to get right: data category, purpose of processing, legal basis, retention period. With that table in hand, the notice writes itself, and the reader can actually find what they're looking for.
Language matters too. The Communiqué expects information to be conveyed in clear, understandable and plain language. In practice we see the opposite: notices get longer, sentences get heavier, and the result becomes unreadable. A notice nobody reads doesn't fulfil the disclosure function. Simplifying it isn't a stylistic choice here — it's what the duty requires.
Keeping the notice current
A data protection notice isn't a document you write once and forget. When a new field is added, a new supplier comes on board, or a new transfer is introduced, the notice needs updating too.
The only sustainable way to manage this is to tie the update to the development process itself. A change that adds a new personal-data field to the data model should trigger an update to both the inventory and the notice. Without that link, the notice drifts away from reality within the first year, and nobody notices.
We built that link into our own site this way: when we added the AI-assisted analysis feature, a separate section explaining the cross-border transfer went into the notice at the same time. The feature didn't go live without it. That's the order it should happen in.

## Why a Data Inventory Comes Before Every Other KVKK Document

Source: https://kulular.com.tr/en/writing/kvkk-compliance

Visit an organisation to help with KVKK compliance work and this is usually what's already in the folder: a privacy notice, a consent form, a retention and destruction policy. All three drafted, signed, filed.
Then one question gets asked. Where did the data categories listed in these documents come from?
The answer is usually: a template found online, the company's name filled in, a few clauses added. In other words, the statement wasn't derived from checking the facts — it was derived from a template. This is the most common, and most costly, sequencing mistake I see in compliance work.
Why the order matters this much
A privacy notice is a statement. Article 10 of Law No. 6698 requires the controller to disclose the categories of data processed, the purposes, the recipients data is transferred to, and the legal basis. If you're making a statement, it has to be accurate.
A notice written without an inventory can't be accurate. At best, it's incomplete. When an audit turns up a processing activity the notice doesn't cover, that isn't just a technical gap — it's a failure to properly discharge the duty to inform.
The reverse is also true. An organisation that already has an inventory writes the privacy notice in a day, because everything that needs writing has already been identified.
What the inventory actually needs to capture
Inventory tables usually get built with three columns: data category, purpose, retention period. Those three aren't enough.
The missing column is: where does this data physically sit? Which database, which table, which field? Is it in the backups too? Is a copy of it sitting in a third-party provider's system?
Without asking that question, the inventory reflects the organisation's own belief about itself, not the underlying reality. The first question asked after a data breach will be "what personal data was on that server" — and an inventory with no physical location recorded is useless at that moment.
Choosing a legal basis is an architectural decision
Article 5 of Law No. 6698 lists the grounds on which processing is permitted. In practice this article is often treated as a formality, but the legal basis chosen directly shapes how the system has to be built.
Where processing relies on explicit consent, that consent can be withdrawn at any time, and processing has to stop the moment it is. That makes three things necessary in the system: a record of which version of the notice the consent was given against, an interface that lets the user withdraw it, and a control that actually stops the relevant processing once consent is withdrawn. Without all three, relying on consent leaves the organisation in an indefensible position.
Processing that's necessary for performance of a contract doesn't need any of that machinery. The same piece of data, processed on a different legal basis, carries an entirely different technical burden. That's why the choice of legal basis should never be made by a lawyer alone, in isolation from the architecture.
Retention periods and the component that enforces them
Setting a retention period is the easy part of a compliance programme. Making sure it's actually applied is the hard part.
A working design looks like this: every record carries its own retention date — a retention_expires field, for example. A job runs on a schedule to find records past that date. The job deletes, destroys or anonymises the record, and writes its own action into a separate log table. What gets shown at audit isn't the policy document — it's that log.
Organisations without this structure typically do the opposite: they write the period into the policy, push implementation to some future date, and that date never arrives. Two years later, there's unerased data sitting alongside a document that says it should have been erased. Having both of those things at once is worse than having no policy at all.
The VERBİS register and its scope
The duty to register with the Data Controllers' Registry (VERBİS) depends on criteria the Board sets: annual staff numbers, balance-sheet size, and the nature of the data processed.
A caution is worth stating here. The scope of the exemption has changed over time through Board decisions and can change again. An organisation exempt today can become subject to the duty once its headcount grows. This isn't a question to settle once and forget — it needs checking annually, against the Authority's current published thresholds.
The breach plan gets written in advance
The fifth paragraph of Article 12 of Law No. 6698 requires a breach to be notified to the Board as soon as possible; Board decisions have fixed that period at seventy-two hours.
Those seventy-two hours are the total time available, once an incident is noticed, to scope it, identify affected individuals, and prepare the notification. Even the first of those steps takes days in most organisations, because there's no written record of what data sits where.
So breach preparation starts long before a breach happens, and it leads back to the same place: the inventory.
What happens once compliance is "done"
It doesn't finish. A new feature creates a new data field. A new supplier creates a new transfer. Board decisions narrow the framework.
That's why compliance works better built into the product-development process than run as a one-off project. If updating the inventory when a new field is added becomes part of code review, the process sustains itself. Otherwise, the work starts over every year, and the same sequencing mistake gets repeated each time.

## Legal Technology: Why Contract-Template Tools Aren't Solving the Real Problem

Source: https://kulular.com.tr/en/writing/legal-technology

Look at how most legal-technology products are marketed and you'll find the same thing: drafting a contract, suggesting a clause, formatting a document. These are useful. But they aren't the field's real problem, and the thing these tools appear to solve is actually the easiest part of it.
The real problem sits somewhere else. An organisation is subject to a legal duty. Someone interprets what that duty means. The interpretation gets written into a document. The document goes into a folder, and the organisation's day-to-day operations carry on unaware it exists. That gap between the document and the running system is the most expensive mistake I see in practice, and no contract-template tool closes it.
Interpretation is a human job; enforcement is the system's job
Turning a rule into software isn't the same as writing the rule into code. There's a step in between that can't be automated.
Article 7 of Law No. 6698 provides that personal data must be deleted, destroyed or anonymised once the reasons requiring its processing no longer apply. That provision is clear. But what does "the reasons no longer applying" mean, precisely, for an organisation's invoice data? The end of the customer relationship? The expiry of the tax-law retention period? Whichever comes later? A lawyer answers that question. The answer is an interpretation, and unless it's put on record, nobody will remember six months later why that particular period was chosen.
That's where the software's job starts: making sure the interpretation, once given, is applied the same way every single time, and that this can be shown. A system that does that is legal technology. A system that only produces templates is a word processor.
What happens when the document and the system come apart
Take a concrete example. An organisation's retention policy says customer contact records are kept for two years. An audit arrives, and that policy gets shown.
The auditor asks one question. What component enforces this period?
Often there's no answer. The database has a created_at field, but no expires_at. There's no job that deletes an expired record. Even where deletion happens, it produces no record of having happened. In the end the organisation can't show that it did what its own policy says. The policy document isn't evidence — at best it's a statement of intent.
The fix isn't a better-written policy. It's adding a field to the data model that carries the retention period, writing a component that enforces it, and making sure that component produces a record when it runs. Once all three exist together, the policy stops being a claim and becomes a description of what the system actually does.
The five links in the chain
Turning a legal text into a working control in a system happens in five steps, and the order matters — skip any one of them and the result becomes unreliable.
First, the provision is identified: the applicable rule and any exception. Then comes interpretation — deciding what the rule means for the concrete business process. This step belongs to a human and has to be put on record. Third, the interpretation is tied to the architecture: which field carries which rule. Fourth, the component that enforces the rule at run time is written. Fifth, that component's operation is logged.
A control built without interpretation enforces the wrong rule. A control that produces no evidence is useless at audit. The mistake I see most often is skipping straight from step three to step five: the organisation keeps a log, writes something into it, but it's unclear what rule that log is actually evidence of.
The lawyers' monopoly
Anyone building a product in this space needs to know one boundary. Article 35 of Law No. 1136 on Attorneys reserves the conduct of legal work and the giving of legal opinions to lawyers.
In practice, this decides what your product can and can't say. "Your contract is missing this clause" is information. "Don't sign this contract, it will work against you" is an opinion. The line is thin and has to be protected deliberately in product design. The most reliable way to protect it is for the system never to make the decision itself, and for a human decision to remain visible behind every output.
That boundary looks like a constraint, but it's actually good design discipline. A system that doesn't take on the decision doesn't take on the responsibility when it gets something wrong — and that stops users trusting the system blindly.
What AI has changed, and what it hasn't
Natural language processing delivers a real productivity gain in document review. Finding a particular clause type across hundreds of contracts used to take weeks. Now it takes hours.
What hasn't changed is responsibility. If a model's output can't be traced back to which document and which paragraph it came from, that output is a guess, not a finding. Likewise, if the system doesn't visibly distinguish a result it's confident about from one it isn't, users trust both equally and errors slip through unnoticed.
Without those two conditions, whatever efficiency gain was made gets paid back later as risk — and the worse part is that nobody knows when that risk will actually materialise.
Where to start
Starting a legal-technology programme inside an organisation, pick a single obligation. Trying to tackle everything at once sounds appealing but never actually finishes in practice.
For the chosen obligation, build all five links: write the provision, put the interpretation on record, connect it to the data model, build the control, produce the evidence. This work finishes in about six weeks, and what you end up with isn't a report — it's a working control and a record you can show at audit.
The second obligation moves much faster. The hard part was never the rule. It was building the chain for the first time.

## In Space, You Are Acting on Behalf of the State, Not Just Your Company

Source: https://kulular.com.tr/en/writing/space-law

There's one rule in space law that works differently from every other field, and most founders learn it late.
Article 6 of the 1967 Outer Space Treaty provides that states are internationally responsible for national space activities. That doesn't change if the activity is carried out by a private company. The article also says these activities require authorisation by, and continuing supervision of, the relevant state.
An example makes this easier to see. A software company that makes a mistake is answerable to its client. A space company that makes a mistake makes the state answerable to another state. The difference isn't one of scale — it's a difference in kind.
How the liability chain is built
The 1972 Liability Convention makes this concrete. A launching state is absolutely liable for damage caused by its space object on the surface of the Earth or to an aircraft in flight — no fault has to be shown.
That has a direct commercial consequence. The state will want to pass this potential liability on to the private operator. That's why authorisation documents typically contain recourse provisions, mandatory insurance and security requirements. If you don't know the size of these line items before entering contract negotiations, you don't know the actual cost of the project either.
Registration follows from the same logic. The 1975 Registration Convention requires objects launched into space to be recorded. Registration establishes which state's jurisdiction and control an object falls under — which is where the answer to "which law applies" begins.
The authorisation map in Türkiye
The Turkish Space Agency was established by Presidential Decree in 2018 and is responsible for preparing the national space programme and coordinating activities.
But space activity isn't confined to a single agency. Frequency and orbital-slot use is a separate regime, governed by International Telecommunication Union rules; domestically, the Information and Communication Technologies Authority is the competent body. Where export controls are involved, other authorities come into play.
Before starting a project, that map needs to be drawn: which permit, from which authority, in what order, and how long it takes. That timeline runs independently of the technical development schedule, and it's usually longer. What delays a project is often not the software — it's the permit.
The data itself is a separate issue
The most common practical problem I see on space projects isn't technical. It's about the data.
Rights over mission data need to be settled in the launch and operations agreements. A gap left in the contract is very hard to fix afterwards, because by then the counterparty already has access to that data, and restricting it retroactively doesn't work in practice.
Earth-observation data raises a separate question. As resolution improves, the likelihood that data qualifies as personal data increases. Imagery that can resolve a vehicle's licence plate is not subject to the same regime as city-scale imagery. When designing a system, the resolution threshold at which a different processing regime kicks in needs to be defined, and built in as a control point in the data pipeline.
The third issue is integrity. It needs to be possible to show the provenance, timestamp and unaltered state of telemetry data. That's the one thing that will carry evidentiary weight in a post-incident review. If there's a possibility the record was produced after the fact, the record itself is worthless as a defence.
The resource-extraction question
Article 2 of the Treaty bans national appropriation. Whether extracting resources from celestial bodies sits against that ban is not settled.
Some states have enacted domestic legislation recognising ownership over extracted resources. How well those laws sit alongside the Treaty is contested, and no settled international practice has yet formed. The honest thing to tell a venture working in this space is this: the legal ground here hasn't settled, and that uncertainty belongs in the investment case as a genuine risk line item. Any view presented as settled is, as things stand, giving incomplete information.
What to bring to the table
Wherever I see the technical team and the legal team working separately on a space project, I see the same problem. Decisions made while writing ground-segment software directly affect the liability regime, and that link is usually noticed only after the contract is signed.
Three things need to be settled before the first negotiation: which authority the authorisation comes from and on what terms; how liability and insurance burden are split between the parties; and who owns, and who can access, the mission data. Technical planning done before these three are resolved usually has to be redone.

## Your Marketing Copy Decides Whether Your Software Is a Medical Device

Source: https://kulular.com.tr/en/writing/health-law

Picture two apps. Both take symptoms the user enters, run an algorithm, and return a list. The code is nearly identical. One falls under medical-device regulation. The other doesn't.
What makes the difference is the description in the app store listing. The first says: "provides information about possible conditions based on your symptoms." The second says: "assesses your symptoms and shows a likely diagnosis." That second sentence puts the product forward for a diagnostic purpose, and with it come risk classification, conformity assessment, a technical file, clinical evaluation and post-market surveillance obligations.
This is the most expensive, and most easily avoidable, mistake I see on health-technology projects. Marketing writes the product description, nobody thinks through its legal consequence, and the product ends up inside a compliance regime it never intended to take on.
The intended-purpose statement is a legal document
The practical rule that follows is this: a product description should be written with the same care as a privacy policy, and reviewed legally before it's published.
The review can't stop at the app-store listing. A headline on the website, a line in a promotional video, a claim in a sales deck, a statement in a support document can all produce the same effect. Saying "provides a diagnosis" in one place doesn't get withdrawn by saying "for informational purposes only" somewhere else.
The decision has to be made upfront. If the product is going to be a medical device, the process that regime requires is built in from the start and priced into the plan as a cost line. If it isn't, keeping every piece of copy within that line becomes a product-development rule.
Access architecture for health data
Article 6 of Law No. 6698 classifies health data as a special category of personal data and subjects it to narrower conditions. The technical counterpart of that classification is missing in most projects.
The pattern I see most often: the application runs, data is stored, but everyone inside the organisation can see everything. Developers can query the production database. Support staff can open a patient record. A manager can see raw data in a report. That means access hasn't actually been restricted, and it's hard to defend at audit.
The right setup starts with role-based access, but doesn't stop there. Every access needs to be logged, the log needs to show who accessed it and for what purpose, and unusual access needs to be detectable. If someone opens a patient record at two in the morning, that has to be visible in the system.
The test environment is a separate issue. Testing with real patient data is the most common, and most dangerous, habit in health technology. Working with masked or synthetic data removes most of that risk and isn't technically difficult to set up.
Clinical decision support and responsibility
AI-assisted decision-support systems raise the question of where responsibility sits. In practice, the safe design is for the system to produce a recommendation and leave the final decision to the qualified health professional.
For that design not to stay theoretical, three things need to be kept together: the recommendation the system produced, the inputs it relied on, and the final decision the health professional made. Kept separately, they can't be matched up later; not kept at all, responsibility can't be shown at all.
One more metric is worth adding: track how often the health professional overrides the system's recommendation. If that rate approaches zero, human oversight has become nominal, and the system is effectively making the decision. That finding can matter a great deal in a later dispute about responsibility.
Remote healthcare
Remote health services in Türkiye operate within Ministry of Health regulations. Which services can be delivered remotely, record-keeping duties and the limits of the service are set out in secondary legislation, and because those rules can change, a product needs to be checked against the current text at design time.
The principle that doesn't change is this: situations that require an in-person examination cannot be handled remotely. A remote-health product needs to be able to recognise a request that crosses that line and redirect it. A system able to say "please see a doctor in person for this" isn't a usability nicety — it's a legal requirement.
Starting a project
In the first meeting on a health-technology project, the question that needs answering isn't what the product will do — it's what it will declare itself to be. Every line of code written before that answer is settled may end up written for the wrong regime.
The second question concerns the data model: what data is genuinely necessary, who can see it, where is access logged, and what happens once the purpose has ended. The answers to those four questions directly shape how the tables are designed, and changing that design later — because it means migrating existing patient data — creates both a technical and a legal problem.

## Does Mandatory Exam-Proctoring Software Pass the Proportionality Test?

Source: https://kulular.com.tr/en/writing/education-law

A student refuses to turn on their camera during a remote exam, saying they don't want their home recorded. The institution says exam integrity has to be protected. Two legitimate interests are facing off here, and the real question isn't which one wins — it's whether the method the institution chose is actually necessary.
This question comes up constantly on education-technology projects, and it usually gets framed the wrong way. The debate turns into "camera on or camera off," when the legal question is narrower: can the same aim be achieved by processing less data?
What proportionality actually asks
Article 4 of Law No. 6698 requires personal data to be relevant to, limited to, and proportionate for the purpose for which it is processed. That principle isn't an abstract aspiration — it's a concrete filter.
Exam integrity is a legitimate aim, no argument there. But a legitimate aim doesn't legitimise collecting every piece of data that could possibly be gathered about a candidate. Continuous video recording, screen capture, keystroke and mouse tracking, installing a client with broad device permissions — each of these has to be assessed on its own, against a single question: is this actually necessary to secure exam integrity, or not?
Often it isn't. Randomising the question bank, time limits, shuffling question order, weighting toward open-ended questions, and post-hoc statistical anomaly detection deliver a serious level of integrity without recording anything at all. Reaching straight for camera recording without first trying these is a hard position to defend on proportionality grounds.
Why consent doesn't work here
The first instinct institutions reach for is asking the student for consent. A checkbox appears before the exam starts, and the student can't sit the exam without ticking it.
The problem with that design is this: valid consent has to be freely given. It's difficult to argue that a student who can't enter the exam without ticking the box is agreeing freely. On top of that, the party on the other side sets grades, records attendance and influences graduation decisions. That power imbalance undermines the consent from the outset.
The practical conclusion is this: relying on consent for student data gives the institution a feeling of security without actually providing legal cover. What the institution should do instead is assess whether the processing rests on some other legal basis — and if it doesn't, drop that processing altogether.
Where a child is involved
For students of compulsory school age, the picture is even more sensitive. Capacity to consent, the parent's role, and the child's best interests all need to be assessed separately here.
When designing an education platform, different flows need to be built depending on the user's age. Offering the same interface to a ten-year-old and a twenty-five-year-old postgraduate student is a problem not just for usability but legally too. A field carrying the age group in the data model, with different processing rules tied to it, is the technical counterpart of that distinction.
What a learning record actually proves
The less-discussed side of education technology is what the record it produces is actually good for afterwards.
When a student appeals a grade, what does the institution have? A "exam completed" record that just closes the ticket — or a chain showing which question got which answer, what criterion it was marked against, and who marked it?
With the second, the appeal is resolved in ten minutes. Without it, the appeal turns into a defence that asks the institution to be trusted on its own record — and that defence is weak. That's why an assessment system should be built in this order: define the learning outcome first, tie the pass criterion to that outcome, generate questions against the criterion, keep a record of the assessment, and define the appeals process and review procedure in advance.
Build that chain, and a certificate of achievement has a demonstrable basis behind it. Without it, the certificate is just a statement resting on the institution's good faith.
What I'd suggest to institutions
Before buying proctoring software, measure how much of the integrity problem can be solved through exam design alone. Most institutions never run that measurement and go straight to the most intrusive option available.
Once that measurement is done, if proctoring is still needed, write a separate justification for every single data point collected. "The system collects this" is not a justification. Any data point that can't be justified should be removed from the system. This should also be a point of negotiation with the vendor, because most off-the-shelf products collect more than you need and ship with those defaults switched on.

## Turkish IT Law Is Hard Because It Isn't in One Statute

Source: https://kulular.com.tr/en/writing/it-law

There is no single answer to "what does Turkish IT law say about this," because there's no single statute called Turkish IT law. That's the first thing anyone working in this field learns, and it's the hardest thing to explain to a client.
In Türkiye, information-technology activity is regulated at the intersection of at least six separate statutes. None of them subsumes any of the others. Each operates on its own logic, with its own sanctions regime, and its own supervisory authority. The result: you cannot draw up a list of obligations by looking at one text, and the same event can produce consequences under more than one regime at the same time.
One data breach can show up in three separate places
A concrete example makes this clearest. Say an e-commerce company's customer database is accessed without authorisation and data is exfiltrated.
The first track is administrative. Article 12 of Law No. 6698 sets out data-security obligations, and its fifth paragraph requires the breach to be reported to the Board. The Board assesses whether the technical and organisational measures taken were adequate, and if it finds them lacking, it can impose an administrative fine.
The second track is criminal. The act of the person who gained access may constitute the offence, under Article 243 of Law No. 5237, of unlawfully accessing an information system, and exfiltrating the data may separately constitute the offence, under Article 136, of unlawfully providing or obtaining data. This investigation runs independently of the company's administrative liability.
The third track is private law. The individual whose data was exposed can claim compensation for the harm suffered — the final clause of Article 11 of Law No. 6698 expressly preserves that right.
These three tracks are not alternatives to each other; they run in parallel. Having paid the Board's fine doesn't end the criminal investigation, and the outcome of a criminal case doesn't itself settle a compensation claim.
What question does each statute actually answer
The most practical way to make sense of how fragmented this field is: work out which question each statute is actually answering.
Law No. 6698 answers "can you process this data?" Conditions for processing, the duty to inform, security measures and the data subject's rights are all here.
Law No. 5651 answers "who is responsible for this content?" The distinctions between content provider, hosting provider, access provider and mass-usage provider, and the procedures for content removal and access blocking, are set out here. The liability regime changes completely depending on which of these four roles a party falls into.
Law No. 5237 answers "is this act a crime?"
Law No. 6563 answers "can you send this commercial message, and what do you, as a service provider, have to disclose?"
Law No. 5070 answers "does this electronic signature stand in for a wet-ink one?"
On a real project, all of these questions usually come up at once. A decision made by looking at only one of them creates blind spots with respect to the other four.
Fragmented authority means fragmented oversight
What makes this even more complex is that different statutes are entrusted to different authorities.
The Personal Data Protection Authority supervises data-processing activity. The Information and Communication Technologies Authority has jurisdiction over electronic communications and is involved in enforcing access-blocking decisions. The Ministry of Trade is responsible for enforcing e-commerce legislation.
The practical consequence: a single product can be answerable to more than one regulator at once, and none of them is bound by another's decision. A favourable view from one doesn't stop another from reaching a different conclusion.
Where mistakes happen in practice
Most of the mistakes I see in this field share one thing in common: the legal assessment happens after the technical decisions have already been made.
The data model is built, tables are created, integrations are written. Just before launch, someone asks a lawyer to "take a look." By that point, options are limited, because anything raised now means retroactive correction — and retroactive correction creates a separate problem for data already collected up to that point.
Yet every one of the following questions could have been answered while the data model was being built. Which categories of personal data will be processed? What legal basis does each category rest on? What's the retention period, and what component enforces it? Which tables get touched when a deletion request comes in? Will there be a transfer abroad?
Five questions. All answerable in a single meeting. The cost of not answering them ends up being many times the cost of that meeting.
The field's real difficulty
The difficulty of Turkish IT law isn't that the rules are complicated. Read individually, they're understandable.
The difficulty is knowing the moment each one switches on. An engineer's decision — "let's log this field too, might be useful" — can trigger consequences under three separate statutes at once, and the person making that call usually has no idea. The way to close that gap isn't a thicker compliance binder. It's having a lawyer at the table when the decision gets made.