Legal review: HC data residency under Ley 25.326

Sub-tickets

Activity

• wi-cli-venus created · 2026-07-05
• wi-cli-venus assigned · 5w ago
  coder-enamel-cc
• coder-enamel-cc note · 1w ago
  NOT MISASSIGNED, recorded so it is not re-routed again. pmmaster-evolutiva-cc asked 2026-10-04 whether this is a code task. It is not, and it is correctly on the enamel PM seat (assignedRole=pm) rather than a coder lane: the deliverable is a legal determination under Ley 25.326 about cross-border transfer of datos sensibles to sa-east-1 and gru1, and no agent can produce it. What an agent CAN produce, and what I will produce on request, is the factual annex the determination needs: which data classes actually land in which region, by table and by code path, with the UNVERIFIED data-residency reference in shared/md/enamel-historia-clinica-standards.md either confirmed or struck. ALSO: this row is the same question ENAMEL-16's owed item (3) reached from the other direction. The two numbers the 09-11 retention ruling left to Elazar - the dispute window for Phase B and the legal retention period for Phase C - are a strict subset of what this row waits on, so answering ENAMEL-1 unblocks those two phases. Phase A needs neither and proceeds independently.
• coder-enamel-cc note · 1w ago
  FACTUAL ANNEX DELIVERED - shared/md/enamel-data-residency-annex.md. The legal determination is still owed by Elazar/counsel and no agent can produce it; this is the half that can be measured, and it is WIDER than the standards doc said. Measured 2026-10-05, each line with its method: (1) Supabase sa-east-1 CONFIRMED - db host resolves to 2600:1f1e:90b:a700::/..., matched against AWS ip-ranges.json synced 2026-10-05-13-07 (2600:1f1e::/36 = sa-east-1). (2) Vercel gru1 CONFIRMED from a live x-vercel-id on /api/health, which ALSO shows an fra1 (Frankfurt, EU) edge the doc never mentions - the EU edge terminates TLS, so request bodies are processed in the EU. (3) THE CLINICAL IMAGE BYTES ARE NOT IN SUPABASE AT ALL: fleet rule evolutiva-commons and enamel_004's profilePictureRef comment send all user-uploaded images to the api-images service, zero storage buckets exist on the ref, and practicaImages (6 REAL rows) holds imageId/checksum/mime/size - a pointer, no bytes. api-images runs on HOSTINGER shared hosting: api.pensanta.com -> 45.132.157.187 and sidecar sql812.main-hosting.eu -> 212.85.3.251, both RIPE RDAP HOSTINGER-HOSTING country BR, owner coder-apiimages-cc. So there are FOUR processors, not two, and the one holding the imaging is neither of the two the residency paragraph names - a transfer basis written against that paragraph does not cover where the imaging lives. (4) The single allow-listed SMTP host is smtp.gmail.com, so any mail body transits Google; enamel has never sent one. (5) Since e9f0f13 enamel writes requester ip+User-Agent into VERCEL RUNTIME LOGS (ENAMEL-68's deliberate alternative to shared appEvents, which ruling msvnjtzzqp5k forbids) - personal data in a store whose region and retention this lane cannot read, and it postdates the doc. Stated limit: RDAP gives the inetnum's REGISTRATION country, not a datacenter attestation. One factual gap left and it is routed, not parked: coder-apiimages-cc is the only seat that can read the hPanel datacenter for web812. Standards doc amended - the residency paragraph now splits MEASURED fact from UNVERIFIED law and checklist row 15 names all four processors. ROW STAYS OPEN: the determination is awaiting-Elazar by construction, and answering it unblocks ENAMEL-16 Phases B and C.