Decisions made by software: the right to object under KVKK, explained for hotels

KVKK Article 11 gives a person the right to object to a result against them that comes solely from automated analysis: software producing an outcome about a person with no human judgment in it. The controller answers requests as soon as possible and within 30 days (Law No. 6698, Article 11, Law No. 6698 on mevzuat.gov.tr (opens in a new tab)).

A CV scored below the line and never opened. A booking cancelled by a risk rule nobody at the desk can explain. In both cases a person was affected by software alone, and the Turkish data protection law gives that person a way to object. Automated decision making under KVKK is not a future problem for hotels: a hotel can already run risk rules, offer targeting and shortlisting tools, and each of them can produce an outcome about a person. After reading this you will know where such results appear, what "solely automated" means, and how to keep a person in the decision so you can prove it later.

What does KVKK Article 11 let a person ask a hotel for?#

Article 11 lists what anyone can ask the data controller, and one item on that list is the right to object to a result against them that comes solely from automated analysis.

The data controller is the hotel. The request goes to the hotel, not to the software vendor, and the hotel answers for what its systems did. The listed rights include learning whether personal data is processed and for what purpose, and knowing the third parties in Türkiye or abroad to whom it was transferred. They also include asking for correction of incomplete or wrongly processed data, and for deletion or destruction.

The objection right is separate from correction: it is not about wrong data, it is about a result the person says should not stand. The controller must conclude the request as soon as possible and within thirty days at the latest, free of charge unless the action involves an extra cost under the Board's tariff, according to the consolidated text of Law No. 6698 on mevzuat.gov.tr (opens in a new tab) (2026-11-01).

KVKK's guide on generative AI, "Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda)" (24 November 2025), states that Article 11 rights apply to generative AI systems, that practical difficulties do not make them inapplicable, and that the rights cover training data, fine-tuning data, model outputs and the content of user queries.

Where could a hotel actually produce such a result?#

Anywhere software scores, ranks, flags or selects a person and no one with real authority changes the outcome.

Recruitment is the clearest case. A tool ranks applications and the lowest scores are never opened. The candidate is rejected by a number and may never learn that a number existed. Reservation risk is another: a rule flags a booking as high-risk from channel, rate pattern or past cancellation, and the hotel cancels it or demands prepayment before arrival.

Offers and upgrades can qualify too. Software decides which guest sees which offer and at what price. A guest who never receives an offer has been treated differently from another guest with the same stay. Staff are data subjects as well: shift assignment, task routing in housekeeping and performance scores all produce outcomes about employees. Guest messaging counts when an assistant answers a complaint and offers a gesture; the reply is an output about that guest, and the guide counts model outputs among the data the rights cover.

Draw the line between a system that informs a person and a system that decides about a person. A revenue report for the manager is the first; a rule that blocks the booking is the second. None of this requires anything called AI. A threshold in a rules engine is automated analysis as well.

What does "solely from automated analysis" mean?#

The Turkish text requires the result to come solely from automated analysis; treat the scope of that word as a question for your adviser rather than a definition you can look up.

The word is narrow by design: where a person genuinely took part in the outcome, the objection right may not be the right route, and correction or another Article 11 head may fit better. The hard case is the reviewer who sees a score, clicks approve and moves on. Do not assume the click settles the question.

Ask your adviser four things: does the reviewer see the input and the reason for the score; can they reverse it without asking anyone; are they independent of the team that set the rule; is the review recorded before the decision takes effect. The guide (opens in a new tab) names the objection right as an important safeguard, and it recommends systematic records, data mapping and data labelling, which is exactly what makes the question answerable later.

The guide also says the Law does not require a data protection impact assessment, but calls one useful where processing uses systems that can significantly affect people's lives. A scoring system that decides who is rejected is a candidate. EU data protection law has a comparable provision; it is not Turkish law and does not settle how the Turkish text reads.

For the questions to bring to your adviser on this and related topics, see our trust and data page.

How do you keep a person in the decision, and prove it later?#

Give one named role the information, the authority and the duty to change the outcome, and record the decision before it takes effect.

Name a role, not a team. "Reservations supervisor" can be asked what happened; "the front office" cannot. Show the reviewer what the system saw and why it scored as it did: a score without its reasons cannot be reviewed, only accepted. Give that person authority to reverse the outcome without escalating. A reviewer who must ask the person who built the rule is not deciding.

Record who reviewed, when, what they saw, what they changed and why. The guide's recommendation of traceability tools and systematic records is the same instruction in KVKK language. Put a clock on the review so "pending" does not become a silent rejection that nobody owns. Review the rule itself on a schedule, not only the individual cases it produces. A rule that is wrong will keep producing defensible-looking decisions. In recruitment, the same discipline applies to shortlisting, interview guides and the notes kept afterwards; see AI for hotel HR: job posts, interview guides and shortlisting.

Guest flags and blacklists: what should the record say, and who may see it?#

A flag is a claim about a person, so it needs a stated reason, a named owner, a retention period and a short list of people allowed to see it.

Separate fact from inference. "Cancelled two bookings on 14 March and 2 April" is a fact. "Problem guest" is an inference and should be labelled as one, with who drew it. Write the reason so a colleague can check it against the reservation history without asking you what you meant.

Keep special categories out. Health, religion, political opinion, union membership and sexual life need stricter conditions under Article 6, and a free-text note field is where they end up by accident. Set an end date: a flag with no expiry becomes a permanent judgment applied to a person who never sees it. Keep the access list short, review it, and be able to say which members of staff opened the record. If the guest asks, the hotel must be able to explain that the flag exists, what it is based on and where it came from, within the same thirty-day frame. Decide in advance which flags feed an automated outcome, because those are the ones the objection right can reach. For what belongs in a profile at all, see what to record in a guest profile, and what never to record.

How do you add this right to your request procedure?#

Add one intake question, one named owner and one log line, and the right stops being a paragraph in a policy and becomes something the hotel can actually answer.

Intake: add the question "was this decided only by software?" to the form or the email template, and record the name of the system involved. Route the request to the owner of that system, not to the front desk. The desk can take the request; it cannot explain a scoring rule.

Answer in plain language: what the system did, what part a person played, and what changed as a result. The guide asks for plain language in the parallel case of informing people about generative AI processing. Start the thirty-day clock on the day the request arrives and keep it visible, because the deadline runs from receipt, not from when the file reached the right desk. If the answer is that no person took part, re-run the decision with a person, record the new outcome, and say so in the reply.

Log the request type, so you can see whether objections about automated results are rare or routine. A routine pattern is a design problem, not a legal one. Update the privacy notice: the guide asks for separate, explicit information about processing through a generative AI system and about processing to develop systems and models, and says people interacting with a chatbot should clearly know they are talking to one. For the wider procedure, see a front office procedure for guest data requests under KVKK.

What to do next#

This week, open your request procedure and add one line: "was this decided only by software?" Then list every system that can produce an outcome about a person without a reviewer who sees the reasons and can reverse them. That list is your real exposure, and it is also the work plan: a named reviewer, a recorded decision and a thirty-day answer for each entry. Confirm the reading of "solely" and your own case with a legal adviser before you rely on it.