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.