OculaWork iki dağıtım modeli sunar. Firma isterse self-host olur: operasyonel verisi (taramalar, öz-değerlendirmeler) kendi adına açtığı, kendi Google Cloud/Firebase hesabında barındırılır — bir başka firmanın verisiyle aynı ortamı paylaşmaz. İstemezse OculaWork'ün paylaşımlı (cloud) altyapısını kullanır; bu durumda operasyonel veri, tenantId ile katı biçimde izole edilmiş ortak bir veritabanında tutulur (bkz. Kullanım Şartları §7.4, §10.8) — iki model de aynı erişim/rıza/saklama garantilerine tabidir. Kimlik doğrulama (e-posta, şifre özeti, rol ataması) her iki modelde de OculaWork'ün merkezi altyapısında tutulur; bu, hesap yönetimini mümkün kılmak için gerekli asgari bilgidir. Self-host'un pratik anlamı şu: operasyonel veriler müşterinin kendi bulut hesabında tutulur; OculaWork'ün bu altyapıya erişimi müşterinin yetkilendirmesine ve sözleşmede belirlenen erişim mekanizmalarına bağlıdır — hesabın sahibi sizsiniz, verdiğiniz erişimi kaldırabilirsiniz.

Kamera görüntünüz hiçbir zaman cihazınızdan çıkmaz. Video, yalnızca tarayıcınızda (RAM'de) işlenir; sunuculara yalnızca hesaplanmış sayısal değerler (göz kırpma oranı, EAR gibi) iletilir.

KAMERA
   │
   ▼
ÇALIŞANIN TARAYICISI
   │
   │  ham görüntü  ─────✕  (cihazdan hiç çıkmaz)
   │
   ▼
EAR / PERCLOS / SAYISAL GÖSTERGE
   │
   ├──────────────►  Çalışanın kendisi        (tam, kimlikli)
   │
   ├──────────────►  Yetkilendirilmiş
   │                 iş yeri hekimi           (tam, kimlikli)
   │
   └──────────────►  Toplulaştırma + eşik + baskılama
                              │
                              ▼
                     Yönetim / İK             (yalnızca toplu istatistik,
                                               kimlik yok, eşik altı gizli)

Aydınlatma ve açık rıza iki ayrı adımdır — tek tıkla birleştirilmez. Açık rıza gereken işlemlerde amaç bazlı, ayrı ve geri alınabilir onay kutuları kullanırız. Her veri işleme faaliyetinin hukuki sebebi açık rıza değildir; uygulanabilir sebep somut işleme bakımından ayrıca belirlenir.

• Genel ölçüm rızası — kamera erişimi ve göz kırpma/yorgunluk ölçümü, temel taramanın gerçekleştirilebilmesi için teknik olarak gereklidir; bu ölçüm olmadan tarama yapılamaz. Bu, işverenin yasal olarak zorunlu tuttuğu bir sağlık gözetimi yöntemi değildir — çalışan rıza vermediğinde yalnızca temel tarama gerçekleşmez.
• Yüz biyometrisi rızası — yalnızca firmanız kimlik doğrulamayı açtıysa istenir, genel rızadan ayrı geri çekilebilir.
• Gelişmiş Fizyolojik Göstergeler rızası — tamamen isteğe bağlıdır, verilmezse temel tarama hiç etkilenmez.

Rıza ekranında artık gerçek bir "Reddediyorum" yolu vardır; rızanın verilmediğine veya geri çekildiğine ilişkin bireysel kayıt işverene aktarılmaz; OculaWork bu bilgiyi çalışan aleyhine bir karar mekanizmasının parçası olarak kullanmaz. Çalışan, ayarlar menüsünden Gelişmiş Fizyolojik Göstergeler rızasını istediği an tek tıkla açıp kapatabilir. Her rıza/ret/geri-çekme olayı, bütünlüğü korunan bir kayıt defterine zaman damgasıyla işlenir; geçmiş kayıtlar olağan uygulama kontrolleriyle hiç kimse (biz dahil) tarafından değiştirilemez. Saklama ve imha işlemleri ilgili mevzuata tabidir — bir uyuşmazlık durumunda bu kayıtlar okunaklı bir rapor olarak çıkarılabilir. Bu, yalnızca bir uygulama kuralı değil, veritabanı erişim kuralı seviyesinde zorlanır (kayıt yalnızca oluşturulabilir; güncelleme/silme isteği — bizim panelimiz dahil — sistemsel olarak reddedilir).

• Ölçüm verileri: iç saklama politikamız kapsamında aktif abonelik + 2 yıl; ilgili mevzuattan doğan yasal saklama süreleri saklıdır.
• Yüz biyometrik şablonu ve cihaz-içi öğrenme model ağırlıkları: aktif abonelik boyunca; "Verilerimi Sil" talebinde veya hesap kapanışında otomatik olarak silinir.
• Hekim klinik notları: yetkilendirilmiş iş yeri hekiminin oluşturduğu sağlık gözetimi kayıtları, ilgili İSG mevzuatında öngörülen saklama süreleri ve KVKK'nın saklama ilkeleri çerçevesinde muhafaza edilir (saklama süresi işin niteliğine ve uygulanabilir yönetmeliğe göre değişir; örneğin Biyolojik Etkenlere Maruziyet Risklerinin Önlenmesi Hakkında Yönetmelik Madde 13/2, maruziyet kayıtlarının maruziyet sona erdikten sonra en az onbeş yıl saklanmasını öngörür — belirli etkenler söz konusu olduğunda bu süre kırk yıla çıkar. Tüm kişisel sağlık dosyaları için geçerli, tek ve genel bir süre iddiasında bulunmuyoruz — uygulanacak süreyi veri sorumlusu kendi faaliyet alanına göre belirler). Kayıtların bütünlüğü korunur, geçmişe dönük değiştirilemez. Silme talepleri, uygulanabilir yasal saklama yükümlülükleri saklı kalmak kaydıyla değerlendirilir.
• "Verilerimi Sil" talebi, tarama sayısı ne olursa olsun (500'den fazla kayıt olsa bile) güvenilir şekilde tamamlanacak biçimde tasarlanmıştır; başarısız olursa kullanıcı açıkça bilgilendirilir, sessizce "başarılı" göstermez.

Bu sayfa, 2026 yılında yapılan kapsamlı bir iç teknik ve mevzuat uyum incelemesinin sonucudur — AB Yapay Zeka Yasası'nın işyerinde duygu tanımayla ilgili hükümleri, KVKK'nın biyometrik veri kararları ve Türk İş Hukuku'ndaki çalışan izleme sınırları esas alınarak, kodun kendisi satır satır incelenmiş; bulunan her boşluk (kimlikli gösterim, eksik saklama süresi, eksik rıza granülerliği gibi) doğrudan düzeltilmiştir. Mükemmel/sıfır-risk iddia etmiyoruz — bu alan (işyerinde biyometrik/fizyolojik veri) hem Türkiye'de hem dünyada hâlâ hızla gelişen bir hukuki alan; ama sistemimizin bilinçli, iyi niyetli ve sürekli gözden geçirilen bir yaklaşımla inşa edildiğini gösterebiliriz.

Somut bir örnek: şirket-geneli toplu istatistikler için k-anonimlik eşiğimiz başlangıçta 5 kişiydi (departman-içi eşikle aynı). Bir iç denetim turunda, hassas biyometrik/fizyolojik verinin şirket-geneli agregatlarda daha yüksek bir eşik hak ettiğini değerlendirip eşiği 10 kişiye çıkardık — bu, kendimizi düzenli olarak sorguladığımızın ve bulduğumuzda iyileştirdiğimizin somut bir kanıtıdır, soyut bir iddia değil.

Bu sayfanın yukarıdaki bölümleri OculaWork'ün kamera tabanlı tarama ürününü kapsar. OculaLearn (uzaktan İSG eğitim modülü, ayrı bir Firebase altyapısında, oculalearn.web.app) farklı bir hukuki dayanağa oturur: 6331 sayılı Kanun Madde 17 ve "Çalışanların İş Sağlığı ve Güvenliği Eğitimleri Uygulama Rehberi" (R.G. Sayı 33212, 2 Nisan 2026). Müfredatın 8 dersi, bu düzenlemenin Ek-1 tablosundan iki bağımsız kaynak okumasıyla çapraz doğrulanarak oluşturuldu.

Sorumluluk ayrımı nettir: OculaLearn'ün resmi eğitim içeriği, ilgili mevzuatın Ek-1 kapsamındaki konuları esas alınarak hazırlanır ve içeriğin güncelliği için makul güncelleme süreçleri uygulanır. Müşteri firmaların "İçerik Geliştir" ile eklediği işyerine özgü konular ve tamamen özel ek eğitimler ise Müşteri'nin sorumluluğundadır — bu içerikler kayıttan önce zorunlu, kimlik/IP/zaman damgalı bir sorumluluk kabul onayı ister ve resmi 60/100 geçme notuna veya sertifikaya asla dahil edilmez. Ayrıntılar için bkz. Kullanım Şartları §10.9.

OculaWork, kullanılan altyapı ve hizmet sağlayıcısına göre kişisel verilerin yurt dışına aktarılabileceği senaryoları ayrı ayrı değerlendirir. Aktarımın gerçekleştiği her senaryoda KVKK Madde 9 ve ilgili ikincil düzenlemelerde öngörülen aktarım mekanizmalarından uygulanabilir olanı kullanılır. Standart sözleşme kullanılan durumlarda taraflar, imza ve Kurum'a bildirim yükümlülüklerini mevzuata uygun şekilde yerine getirir.

Bugün itibarıyla ilgili olabilecek başlıklar:

• Barındırma — veriler Google Firebase / Google Cloud'un Avrupa bölgesinde tutulur. Avrupa'da saklanıyor olması, sağlayıcının destek erişimi veya alt işleyicileri yoluyla AB dışına aktarım ihtimalini tek başına ortadan kaldırmaz.
• E-posta gönderimi — bildirim altyapısı sağlayıcısı Amerika Birleşik Devletleri merkezlidir. Bu kanaldan bireysel ölçüm sonucu, yorgunluk/risk skoru veya sağlıkla ilişkili kişisel değerlendirme gönderilmez; içerik şablonludur (bkz. Kullanım Koşulları EK-0.3C).
• Kurumsal kurulum — Platform müşterinin kendi sunucusunda çalıştığında çalışan verisi bu altyapılara hiç girmez; yalnızca sözleşmede sayılı, sınırlı alanlar merkeze ulaşabilir ve bu kanal varsayılan olarak kapalıdır.

Aktarım mekanizmasının somut olayda yeterli olup olmadığı, veri sorumlusunun kendi değerlendirmesi ve hukuk danışmanının incelemesiyle belirlenir. Bu sayfa o değerlendirmenin yerine geçmez.

OculaWork offers two deployment models. A company can choose to be self-hosted: its operational data (scans, self-assessments) is hosted in its own Google Cloud/Firebase account, opened in its own name — it never shares an environment with another company's data. Or it can use OculaWork's shared (cloud) infrastructure, where operational data lives in a common database strictly isolated by tenantId (see Terms of Use §7.4, §10.8) — both models carry the same access/consent/retention guarantees. Identity data (email, password hash, role assignment) is kept on OculaWork's central infrastructure in either model — the minimum needed to make account management possible. In practical terms, self-hosting means operational data is held in the customer's own cloud account; OculaWork's access to that infrastructure depends on the customer's authorisation and on the access mechanisms set out in the contract — you own the account, and you can withdraw the access you granted.

Your camera feed never leaves your device. Video is processed only in your browser (RAM); only computed numeric values (blink rate, EAR, etc.) are sent to the servers.

CAMERA
   │
   ▼
EMPLOYEE'S BROWSER
   │
   │  raw footage  ─────✕  (never leaves the device)
   │
   ▼
EAR / PERCLOS / NUMERIC INDICATOR
   │
   ├──────────────►  The employee themselves   (full, identified)
   │
   ├──────────────►  Authorised occupational
   │                 physician                 (full, identified)
   │
   └──────────────►  Aggregation + threshold + suppression
                              │
                              ▼
                     Management / HR           (aggregate statistics only,
                                                no identity, below-threshold
                                                groups hidden)

Disclosure and consent are two separate steps — never merged into one click. For processing that requires explicit consent we use purpose-based, separate and revocable checkboxes. Explicit consent is not the legal basis for every processing activity; the applicable basis is determined separately for each concrete processing operation.

We use separate, independent checkboxes for different processing purposes:

• General measurement consent — camera access and blink/fatigue measurement are technically necessary for the basic scan to be performed; without them no scan can take place. This is not a health-surveillance method mandated by law on the employer; where an employee declines, the basic scan simply does not run.
• Facial biometric consent — requested only if your company enabled face verification; revocable independently of general consent.
• Advanced Physiological Indicators consent — entirely optional; declining it doesn't affect the basic scan at all.

The consent screen now has a genuine "I Decline" path; the individual record of a consent not being given or being withdrawn is not transmitted to the employer, and OculaWork does not use this information as part of any decision mechanism operating against the employee. Employees can toggle their Advanced Physiological Indicators consent on/off anytime, with one tap, from the settings menu. Every consent/decline/withdrawal event is timestamped into an integrity-protected log; historical entries cannot be altered through ordinary application controls, by anyone, including us. Retention and deletion are subject to applicable legal obligations — in a dispute, this can be exported as a readable report. This isn't just an application-level rule — it's enforced at the database access-rule level (the record can only be created; any update/delete request — including from our own admin panel — is systemically rejected).

• Scan data: under our internal retention policy, active subscription + 2 years, subject to applicable statutory retention obligations.
• Facial biometric template and on-device learning model weights: for the duration of the active subscription; deleted automatically upon a "Delete My Data" request or account closure.
• Physician clinical notes: health-surveillance records created by the authorised occupational physician are retained in line with the retention periods prescribed by applicable OSH legislation and KVKK's retention principles (the retention period varies with the nature of the work and the applicable regulation; for example, Article 13/2 of the Regulation on the Prevention of Risks from Exposure to Biological Agents requires exposure records to be kept for at least fifteen years after exposure ends — extending to forty years for certain agents. We make no claim of a single, general period covering all personal health files — the applicable period is determined by the data controller for its own field of activity). Record integrity is preserved and retroactive alteration is prevented. Deletion requests are assessed subject to any applicable statutory retention obligations.
• "Delete My Data" requests are designed to reliably complete regardless of record count (even 500+ records); if it fails, the user is clearly told — it never silently reports "success."

This page is the result of a comprehensive internal legal/technical audit conducted in 2026 — grounded in the EU AI Act's workplace emotion-recognition provisions, Turkish KVKK biometric-data decisions, and Turkish labor law limits on employee monitoring, with the code itself reviewed line by line; every gap found (identified display, missing retention periods, insufficient consent granularity) was fixed directly. We don't claim perfection or zero risk — this area (workplace biometric/physiological data) is still a rapidly evolving legal field, both in Turkey and globally — but we can show that our system was built with a deliberate, good-faith, continuously-reviewed approach.

A concrete example: our k-anonymity threshold for company-wide aggregate statistics originally started at 5 people (the same as the department-level threshold). During an internal audit round, we determined that sensitive biometric/physiological data deserved a higher threshold at the company-wide aggregate level, and raised it to 10 people — concrete evidence that we regularly question ourselves and improve when we find something, not just an abstract claim.

The sections above cover OculaWork's camera-based scanning product. OculaLearn (the remote OHS training module, on separate Firebase infrastructure at oculalearn.web.app) rests on a different legal basis: Law No. 6331 Article 17 and the "Implementation Guide for Employees' Occupational Health and Safety Training" (Official Gazette No. 33212, April 2, 2026). Its 8-lesson curriculum was built from that regulation's Annex-1 table, cross-verified via two independent source readings.

The liability split is explicit: OculaWork is responsible for the accuracy of the official Annex-1 curriculum. Workplace-specific topics and fully custom extra trainings that customer companies add via "Develop Content" are the Customer's responsibility — this content requires a mandatory, identity/IP/timestamp-logged liability acknowledgment before saving, and is never counted toward the official 60/100 pass score or certificate. See Terms of Use §10.9 for details.

OculaWork assesses separately each scenario in which personal data may be transferred abroad, depending on the infrastructure and service provider used. Wherever a transfer occurs, the applicable mechanism among those set out in KVKK Article 9 and its secondary legislation is used. Where a standard contract is used, the parties fulfil the signature and Board-notification obligations in accordance with the legislation.

Headings that may be relevant as of today:

• Hosting — data is held in the European region of Google Firebase / Google Cloud. Storage in Europe does not, on its own, eliminate the possibility of transfer outside the EU through the provider's support access or sub-processors.
• Email delivery — the notification infrastructure provider is based in the United States. No individual measurement result, fatigue/risk score, or health-related personal assessment is sent through this channel; content is templated (see Terms of Service APP-0.3C).
• Enterprise deployment — when the Platform runs on the customer's own server, employee data never enters these infrastructures; only the limited fields enumerated in the agreement may reach the centre, and that channel is off by default.

Whether a transfer mechanism is sufficient in a concrete case is determined by the data controller's own assessment and its legal counsel's review. This page does not substitute for that assessment.