Go-live sonrasında evidence çalışması başlar

Go-live çoğu projede finish line gibi görünür. Test geçmiştir, owner onaylamıştır, integration çalışır ve system günlük operation'a girer. Sonra „operasyon" devralır. Riskli boşluk tam burada oluşur: Project team dağılırken gerçek population, actual data, workaround ve rare failure ilk kez görünür olur.

Lab expected case'i simüle eder; market yeni kombinasyon üretir. User farklı ifade kullanır, source format değiştirir, staff shortcut geliştirir, provider model günceller ve downstream system output'u başka amaçla yorumlar. Go-live sonrası iş yalnız maintenance değildir. System'ın değerlendirildiği purpose ve sınırlar içinde kalıp kalmadığını sürekli test eden evidence çalışmasıdır.

Post-market monitoring genişletilmiş uptime dashboard değildir

Technical operation availability, latency, cost ve error code ölçer. Bunlar önemlidir fakat AI'ın suitable, safe ve compliant kaldığını göstermez. System sürekli erişilebilirken yanlış priority üretebilir, küçük bir group'u dezavantajlı bırakabilir veya intended purpose dışında kullanılabilir.

EU AI Act Madde 72, high-risk system için documented post-market monitoring ister. Relevant data system lifetime boyunca active ve systematic şekilde collected, documented ve analysed olmalıdır. Amaç continuous compliance değerlendirmesidir. Monitoring plan technical documentation'ın parçasıdır. Yani monitoring; question, source, threshold, owner ve decision içeren measurement architecture'dır, tesadüfen biriken telemetry değildir.

Güçlü plan şunları sorar: System hakkında hangi claim'ler geçerli kalmalı? Hangi signal bunları yanlışlayabilir? Signal nerede oluşur? Kim hangi cadence ile inceler? Hangi threshold investigation, restriction, correction veya stop başlatır?

Intended purpose operational baseline kurar

Monitoring reference state ister. Bu yalnız model number değildir: intended purpose, population, user role, decision impact, data source, workflow, integration, human oversight, known failure mode ve accepted residual risk birlikte baseline oluşturur.

Temel soru şudur: System hâlâ assessment'ın dayandığı assumption içinde mi çalışıyor? Başlangıçta summary üreten assistant'ın output'u daha sonra otomatik approval belirliyorsa yalnız kullanım sıklığı değişmemiştir; decision influence büyümüştür. İyi monitoring statistical drift yanında purpose ve process drift'i de yakalar.

Her baseline stable identifier ve validity period taşır. Change history'yi overwrite etmez. Böylece belirli zamanda hangi version, purpose, data ve control'un geçerli olduğu reconstruct edilebilir.

Dört drift türü ayrılmalıdır

1 · Data drift: Input distribution, format, completeness veya provenance değişir.

2 · Concept drift: Input ile desired outcome arasındaki ilişki değişir.

3 · Process drift: İnsan veya system output'u farklı kullanır; advice fiilen decision olur.

4 · System drift: Model, prompt, retrieval corpus, tool, threshold veya provider platform değişir.

Data drift quality ve representativeness analysis gerektirebilir. Concept drift domain reassessment ister. Process drift training, role change veya functional limit doğurabilir. System drift change control'a ve gerekirse yeniden risk/conformity assessment'a girer.

Tek drift score yeterli değildir. Monitoring technical signal'ı workflow observation, user feedback ve real effect ile bağlar.

Outcome model metric'ten önemlidir

Accuracy, failure rate ve retrieval hit rate ara ölçüdür. Asıl soru output sonrası ne olduğudur. False recommendation fark edildi mi? Human reviewer anlamlı şekilde disagree edebildi mi? Delay, disadvantage veya workload oluştu mu? Complaint çözüldü mü? Correction yalnız interface'i mi durdurdu, downstream process devam mı etti?

Evidence chain run, data state, output, human decision, downstream action ve observed outcome'u bağlar. Model error; integration error, misuse ve poor workflow design'dan ayrılır. Doğru action ancak bu ayrımdan sonra seçilebilir.

Group ve scenario analysis gerekir. Stable average küçük population'daki degradation'ı saklayabilir. Relevant segment önceden tanımlanır ve data minimisation ile incelenir. Segment analysis hukuken veya pratikte mümkün değilse uydurma güven yerine alternative assurance kullanılır.

Log ancak interpretation rule ile evidence olur

Madde 12 high-risk system'ın relevant event'ı automatically record edebilmesini ister. Daha fazla log otomatik olarak daha fazla proof değildir. Version, timestamp, identity, process step ve outcome içermeyen event pahalı data fog üretir.

Evidence event; event type, time, system/configuration version, relevant data reference, responsible role, decision, effect ve predecessor bağlantısını içerir. Sensitive content ihtimal için tamamen kopyalanmaz; reference, hash, minimised feature ve retention rule traceability ile data protection'ı bağlayabilir.

Interpretation rule signal'ın anlamını tanımlar. Üç timeout availability issue olabilir. Aynı case group'ta üç human override domain gap gösterebilir. Hypothesis ve threshold olmadan dashboard dekorasyondur.

Provider ve deployer closed information loop kurmalıdır

Provider product change'i görür ama full deployment context'i görmeyebilir. Deployer real case, complaint ve workaround'u görür fakat her technical dependency'yi bilmeyebilir. Monitoring ancak structured information exchange ile çalışır.

Madde 26 deployer'dan instruction'a uygun kullanım, competent human oversight, operation monitoring ve gerektiğinde provider'a bilgi ister. Instruction'a uygun kullanımın bile risk oluşturduğuna dair neden varsa provider/distributor ve ilgili market surveillance authority undue delay olmadan bilgilendirilir ve kullanım suspend edilir. Serious incident ek route'ları aktive eder.

Operating agreement yalnız service level değil evidence protocol içermelidir: ortak event taxonomy, secure transmission, contact, readiness, deadline, permissible data, clarification ve closure confirmation. Support mailbox closed loop değildir.

Complaint ve near miss early sensor'dır

Harm önce system error olarak görünmeyebilir. Etkilenen kişi incomprehensible decision anlatır, staff recommendation'ı bypass eder, uzman shadow list tutar ve customer process'i bırakır. Bu signal'lar her complaint'i hemen model defect saymadan monitoring'e girmelidir.

Complaint record channel, case reference, version, impact, group, investigation, response ve correction'ı bağlar. Repeated pattern aggregate edilir. Oversight veya şansın harm'ı önlediği near miss korunur. Yalnız gerçekleşen zararları saymak en değerli prevention data'yı kaybetmektir.

Incident response incident'tan önce başlar

Madde 73 serious incident için kademeli reporting deadline içerir. Genel olarak causal link veya reasonable likelihood kurulduğunda hemen ve awareness sonrası en geç 15 gün içinde report verilir. Bazı özellikle ağır durumlarda daha kısa maximum period vardır; zamanında initial incomplete report verilip sonra tamamlanabilir.

Bu süreler internal action target değildir. Detection, triage, evidence preservation ve activation daha erken olur. Runbook şu soruları cevaplar: System'ı kim disable eder? Investigation'ı bozmadan log'u kim korur? People impact'i kim değerlendirir? Provider, deployer, authority ve diğer tarafları kim bilgilendirir? Bir signal'ın reportable olmadığı kararı kim tarafından nasıl kaydedilir?

Uncontrolled change sonraki cause evaluation'ı bozmamalıdır. Configuration, version ve artefact freeze edilir veya reproducible şekilde korunur; aynı anda affected person korunur ve further harm önlenir.

Her change evidence gate ister

AI system sık değişir. Provider base model update eder, retrieval corpus büyür, prompt optimize edilir, tool permission artar veya source eklenir. Her change performance, risk, transparency, oversight ve purpose'u etkileyebilir.

Madde 17 quality management system içinde modification procedure, development öncesi/sırası/sonrası test, post-market monitoring, incident reporting, record keeping ve accountability ister. „Minor prompt improvement" yazan ticket yetmez. Gate affected claim, new failure path, data change, regression test, documentation, rollback ve approval'ı değerlendirir.

Change class file size'a değil impact'e göre seçilir. Tek new tool permission büyük internal refactor'dan riskli olabilir. New model version; comparison data, boundary case, oversight ve reversal test edilmeden production'a geçmez.

Corrective action patch'ten büyüktür

High-risk system non-conforming ise Madde 20 immediate appropriate corrective action ister. Duruma göre conformity'ye getirme, withdrawal, disabling veya recall gerekir. Relevant distributor, deployer, representative, importer, authority ve gerekirse notified body bilgilendirilir.

Corrective Action Record problem, scope, affected version/deployment, immediate protection, root cause, lasting action, validation, communication ve closure criterion içerir. Downstream effect de incelenir: Decision yeniden review edilmeli mi, people bilgilendirilmeli mi, data product yeniden üretilmeli mi? Software patch oluşmuş etkiyi iyileştirmez.

En küçük faydalı monitoring architecture

Küçük provider dev control room kurmak zorunda değildir. Minimum yapı altı linked register'dan oluşur:

Baseline: purpose, version, population, data, control ve residual risk.

Signal: metric, threshold, complaint, drift ve near miss.

Change: modification, impact, test, approval ve rollback.

Incident: triage, evidence, reporting, investigation ve protection.

Action: correction, owner, deadline ve effectiveness review.

Review calendar: daily alert, periodic review ve event-triggered reassessment.

Technology basit olabilir; stable identifier ve relation kritiktir. Complaint'ten run'a, version'a, change'e ve corrective action'a gidilebilmelidir.

Yöntem: BASELINE → SIGNAL → TRIAGE → CHANGE → VERIFY

BASELINE geçerli system claim'i sabitler. SIGNAL technical ve human observation toplar. TRIAGE impact, urgency ve reporting route'u değerlendirir. CHANGE bounded correction veya adaptation uygular. VERIFY action ve documentation'ın cause'u gerçekten giderip gidermediğini kontrol eder.

Son adım loop'u kapatır. Effectiveness review yoksa monitoring ticket factory olur. Varsa operation; negative evidence'ı saklamayan, daha iyi boundary ve decision'a dönüştüren controlled learning system olur.

Çalışma kâğıdı: Post-market monitoring plan tasarla

1. Purpose, version, population ve decision impact tanımla.

2. Operation'da geçerli kalması gereken beş claim yaz.

3. Her claim'e technical, human ve outcome signal bağla.

4. Review, pause, correction ve incident triage threshold'u tanımla.

5. Provider-deployer information loop'u tasarla.

6. Change ve regression-test gate'ini belirle.

7. Complaint, near miss ve log'u action'a bağla.

8. Review cadence, owner ve effectiveness check planla.

Yansıtma: Mevcut dashboard hangi system claim'i test edemiyor? Hangi gerçek change bugün fark edilmeden production'a girebilir?

İndirilecek tüm materyaller — konu özeti ve çalışma kâğıdı:

Kapsam: Makale profesyonel operating-evidence model sunar, hukuk danışmanlığı değildir. Aktarılan şartlar özellikle high-risk AI system'ları ilgilendirir; risk-proportionate parçalar başka sistemlerde voluntary kullanılabilir. Sectoral, data protection, employment, product ve national law ayrıca incelenmelidir. Editoryal inceleme: 17 Temmuz 2026.