ANSPDCPルーマニア：CNP検出とGDPRチェック
2026年版に更新
ルーマニアのデータ保護機関はANSPDCPです。2024年の評価では、現地のアウトソーシング企業が使用するPIIツールの78%がCod Numeric Personal（CNP）を正しく検出できないことが判明しました。ほとんどのツールはチェックサムの検証ステップを省略しています。このギャップは深刻なコンプライアンスリスクをもたらします。ルーマニアは多くの西欧クライアントのEUデータを処理しています。リスクの範囲は広大です。
ルーマニアで最もデータ量の多い国民識別番号
CNPは13桁の国民識別番号です。各桁グループには個人データが含まれます：
- 第1桁： 性別と世紀コード。1900–1999年生まれ男性 = 1。1900–1999年生まれ女性 = 2。2000年以降生まれ男性 = 5。2000年以降生まれ女性 = 6。男性外国人居住者 = 7。女性外国人居住者 = 8。その他の居住者 = 9。
- 第2–3桁： 生まれ年の下2桁。
- 第4–5桁： 生まれ月（01–12）。
- 第6–7桁： 生まれ日（01–31）。
- 第8–9桁： 郡コード。ルーマニアの41郡とブカレストの6区域をカバー（コード01–52）。
- 第10–12桁： その日・郡における出生順序。
- 第13桁： チェックデジット。
第1桁だけで生物学的性別が判明します。GDPR第9条のもと、この番号は特別カテゴリのデータ項目となります。通常の個人データより強い保護が必要です。
チェックデジットの仕組み： 最初の12桁を取ります。それぞれをその重み（2, 7, 9, 1, 4, 6, 3, 5, 8, 2, 7, 9）で掛けます。結果を合計します。11で割り、余りを求めます。余りが10の場合、チェックデジットは1です。余りが11の場合、コードは無効です。それ以外の余りがチェックデジットになります。
このテストを省略したツールには2つの失敗パターンがあります。第一に、13桁の任意の文字列が一致としてフラグ付けされます（偽陽性）。第二に、破損した番号がパターンチェックを通過しますが、不正なデータを含みます。そのデータは見落とされ、レビューされません（偽陰性）。
ルーマニア語文書でのNERの課題
識別子を見つけることは作業の一部に過ぎません。ルーマニア語テキストはさらなる検出障壁をもたらします。
発音区別符号： ルーマニア語ではș、ț、ă、â、îを使用します。他の言語で訓練されたツールは、これらの文字を含む名前を見落とすことがよくあります。Latin-2エンコーディングの古い文書はさらに多くの検出失敗を引き起こします。
住所フォーマット： 通りの種類には短縮形が使われます — Str.、Bd.、Al.、Cal.。市や自治体名はローカルルールに従います。フランスやドイツの住所向けに構築されたパーサーはここでは精度が低いです。
名前の格変化： ルーマニア語では名前が文法的な格によって変化します。同じ人の名前が文の異なる部分で異なって見えます。NERモデルは文書全体で名前を結びつけるためにこれを処理する必要があります。
言語ギャップが非西洋文字の検出にどう影響するかは、APAC PII検出ガイドをご参照ください。
ANSPDCPの事例の展開パターン
ANSPDCPの事例には3つのパターンがあります。
BPOデータ侵害の事例： 共有ファイルには従業員のID番号とEU顧客データが暗号化なしで保存されています。不十分なログにより、企業はどのレコードにアクセスされたか把握できません。これにより調査が長期化し、罰金が増加します。
医療データの漏洩： 患者ファイル — 国民ID、健康保険IDと診断 — が誤った相手に届きます。PIIツールはこの形式をサポートしていませんでした。データはマスキングなしで送信されました。
越境転送の失敗： アウトソーシング企業が識別子にリンクしたレコードをEEA域外の相手に送信します。Transfer Impact Assessmentなし。Standard Contractual Clausesなし。データの第9条のステータスにより、通常のギャップがより深刻な違反になります。
ANSPDCPコンプライアンスのための3つのコントロール
これら3つが最低限の技術的基準を形成します：
- モジュロ11検証によるCNP検出 — パターンマッチングだけでは不十分です。
- 発音区別符号対応NER — UTF-8とLatin-2ソースでș、ț、ă、â、îをカバー。
- 身分証明書の検出 — 国民カードは多くの文書タイプでCNPと並んで登場します。
国民IDがGDPRリスクをどのように生み出すかの詳細は、EU国別税務識別番号検出ガイドをご参照ください。