REGULATORY POSITION & DATA PROTECTION

Software that touches surgical decisions must be honest about two things: what it is regulated as, and what happens to the data it is given. This page states both plainly — including what has not been completed yet.

DESIGNED AGAINST THE CDS CRITERIA

RLES AI is built to function as non-device Clinical Decision Support under the criteria the FDA sets out in its Clinical Decision Support Software guidance. That is a design principle, not a claim of authorisation — and it shapes the product at every level:

The fourth criterion is why explainability is not a marketing feature here but an architectural requirement: a surgeon who cannot audit a recommendation cannot be expected to own the decision that follows it.

WHERE THE REGULATORY WORK STANDS TODAY

• RLES AI is not FDA cleared or FDA approved, and it does not carry a CE mark. No submission has been filed. Any statement to the contrary — by anyone — is incorrect.
• Regulatory strategy for both the United States and the European Union is being developed with external regulatory advisors; this work is ongoing and no timeline is claimed here.
• The platform runs as a controlled clinical pilot with registered surgeons. It is offered as decision support for licensed professionals — not as a diagnostic device, and never to patients directly.
• In the US Edition, modules that depend on image analysis or on generating a treatment value the surgeon could not independently derive are disabled pending the outcome of that regulatory work. This is a deliberate restriction, applied before anyone asked for it.

TWO CHANNELS, ONE OF THEM FOR PATIENT DATA

The separation below is the single most important fact on this page, because it decides where clinical data can and cannot appear:

The Mobile Interface is a mobile web interface the surgeon adds to the phone's home screen — not an application installed from a store, and with no third-party mobile SDK in the path. Investigations are uploaded there, reports open there and are saved from there. The WhatsApp line is used for training and authentication messages only — teaching, questions about rules and nomograms, access links and notifications. Patient data is not shared over WhatsApp.

DATA PROTECTION BY ARCHITECTURE

The strongest privacy guarantees are the ones built into how a system is wired, not the ones written in a policy. These are facts about the platform's architecture:

• This website never receives patient data. The clinical service runs on separate, dedicated infrastructure; www.rlesai.com collects only what an information request form collects.
• Regional hosting. Data of patients in Türkiye is held on servers in Türkiye; data originating in every other country is held on servers in the European Union. Residency follows the patient's country, not the company's — which is why the Turkish deployment exists at all.
• Each surgeon's workspace is isolated. A surgeon reaches only their own cases; the platform administrator can open a surgeon's case only through a separate, named path, and every such access is logged with who, which surgeon and which case.
• Access is protected by a PIN the surgeon sets and that RLES AI cannot read — it is stored hashed. A forgotten PIN is replaced, never recovered.
• An unfinished form is kept on the surgeon's own phone so a half-filled patient card is not lost; that draft never reaches the server and is deleted when the form is saved.
• Voice notes are transcribed locally on RLES AI's own server — audio is never sent to a third-party speech service.
• No third-party model brokers. Clinical requests go directly to the language-model provider under a business agreement; no intermediary routing service sits in the path.
• Data minimisation: the platform works from the values a surgeon chooses to send. Patient identifiers are not required for a plan to be produced, and de-identified working is the platform default: the line asks every surgeon to use a protocol number or pseudonym instead of the patient's name.
• Every extracted value is confirmed by the surgeon before it enters a calculation — a safety rule that doubles as a data-integrity control.

GDPR & KVKK: WHO ANSWERS FOR WHAT

Transparency starts with naming the roles precisely. Under the GDPR — and under its Turkish counterpart, the KVKK — the roles on this platform are as follows:

• For patient data, the surgeon is the data controller. The physician already owes the patient a duty of medical confidentiality; the physician informs the patient, obtains explicit consent where the law requires it, and answers for the accuracy of the values submitted.
• RLES AI is the data processor. MCD Teknoloji Yatırımları San. ve Tic. A.Ş. — the platform's owner and operator, established in Türkiye within the MCD group — analyses clinical data on the surgeon's behalf and on the surgeon's instruction, solely to produce the requested analysis or report. It does not use the data for its own purposes, does not transfer it to third parties for theirs, does not sell it, and shows no advertising.
• The only sub-processing is what this page describes: regional hosting (Türkiye or the European Union, following the patient's country) and model processing under a direct business agreement bound by confidentiality. No other party touches clinical data — and the messaging channel is deliberately outside this list, because patient data does not travel through it.
• For website form data, MCD is the controller — that narrower scope is covered by the Privacy Policy.

Patients hold the rights the GDPR (Articles 15–22) and KVKK Article 11 grant — access, rectification, erasure, restriction and objection — and exercise them through their surgeon as controller; RLES AI supports the surgeon in fulfilling any such request, including deletion of case records. Complaints may be addressed to the Turkish Personal Data Protection Authority or the competent EU supervisory authority. This section is an informational statement of roles, not a compliance attestation; the formal framework below completes it.

Where the data sits is part of the answer. Data of patients in Türkiye is processed and stored in Türkiye, so the routine clinical use of the platform by a Turkish surgeon does not depend on a cross-border transfer under Article 9 of the KVKK. Data originating in other countries is processed within the European Union, where the GDPR applies directly. The written data processing agreement between the surgeon and MCD — retention periods, deletion, sub-processors and the surgeon's instructions — is the instrument that completes this architecture, and it is prepared with legal counsel. This statement belongs to the test (pilot) phase: the platform operates as a clinical pilot limited to registered surgeons, and de-identified working — a protocol number or pseudonym instead of the patient's name — is applied as the platform default throughout.

ENCRYPTION IN TRANSIT: THE APP, THE LINE AND THE SITE

Clinical data moves in exactly one place — between the surgeon's app and RLES AI's own server — and it moves encrypted the whole way:

• From the Mobile Interface to the server, every request travels over TLS 1.2/1.3 to infrastructure operated by RLES AI in the patient's own region. No messaging provider sits on this path: uploads, analyses and reports never leave the interface-to-server connection.
• The WhatsApp line carries training and authentication messages — teaching, questions, access links and notifications — under WhatsApp's Signal-protocol encryption to the Cloud API and TLS onwards to RLES AI's server. Meta operates that channel under its business terms; we state that plainly rather than claiming no one sits on the path. Patient data is not shared over this channel, so no clinical record depends on it.
• What never travels at all is a protection of its own: voice notes are transcribed on RLES AI's server rather than sent to a speech service, no intermediary model broker sits in the path, and de-identified working is the platform default — a protocol number or pseudonym in place of the patient's name.
• Encryption of this kind is precisely the class of technical measure that Article 32 GDPR and Article 12 KVKK require of those who process personal data — stated here as a description of the architecture, consistent with this page's rule of never self-certifying compliance.

The website is a different matter, deliberately: www.rlesai.com never receives patient data — there is nothing on this site into which clinical information could even be typed. It is nevertheless served entirely over HTTPS: TLS 1.2/1.3 with an automatically renewed Let's Encrypt certificate, forced redirection of all plain-HTTP requests, HSTS and a restrictive content-security policy. Transport encryption protects data in motion; the role separation above governs what happens to it afterwards — the two belong together.

BEFORE GENERAL AVAILABILITY

The pilot phase is deliberately narrow, and several items are openly outstanding. Before RLES AI is offered for general use, the following will be completed rather than assumed:

• A formal data-protection framework covering GDPR and KVKK — the signed data processing agreements and the published retention schedule (data residency is settled: the patient's own region) — and HIPAA arrangements, including business associate agreements, for any use involving protected health information in the United States
• Conformity assessment for the European market and the corresponding regulatory pathway for the United States
• Publication of the resulting documentation on this page — with dates, so that claims can be checked rather than trusted