ಡೇಟಾ ಸೋರಿಕೆ ತಡೆಗಟ್ಟುವಿಕೆ ಮತ್ತು PII ಮರೆಮಾಚುವಿಕೆ

ಲಾಭಗಳು:

• ಪ್ರಾಂಪ್ಟ್, ಲಾಗ್, ಔಟ್‌ಪುಟ್ ಮತ್ತು ತರಬೇತಿಯ ಮೂಲಕ ಡೇಟಾ ಸೋರಿಕೆ ವೆಕ್ಟರ್‌ಗಳನ್ನು ಗುರುತಿಸುವ ಸಾಮರ್ಥ್ಯ
• ಮಾದರಿಗೆ ಕಳುಹಿಸುವ ಮೊದಲು PII ಡೇಟಾವನ್ನು ರಿಡಕ್ಷನ್ ಅಥವಾ ಟೋಕನೈಸೇಶನ್‌ನೊಂದಿಗೆ ಮರೆಮಾಚುವ ಸಾಮರ್ಥ್ಯ
• ಭದ್ರತಾ ವಿನ್ಯಾಸದಲ್ಲಿ ಶೂನ್ಯ ಡೇಟಾ ಧಾರಣ (ZDR) ಮತ್ತು ಡೇಟಾ ರೆಸಿಡೆನ್ಸಿ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಸಾಮರ್ಥ್ಯ

ಸಂಸ್ಥೆಯ ಅತ್ಯಂತ ದುಬಾರಿ AI ದುರ್ಘಟನೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಅಲಂಕಾರಿಕ ಜೈಲ್ ಬ್ರೇಕ್ ಆಗಿರುವುದಿಲ್ಲ, ಆದರೆ ರನ್-ಆಫ್-ದ-ಮಿಲ್ ಡೇಟಾ ಸೋರಿಕೆಯಾಗಿದೆ: ಒಬ್ಬ ಉದ್ಯೋಗಿ ಸೂಕ್ಷ್ಮ ಗ್ರಾಹಕ ಫೈಲ್ ಅನ್ನು ಸಹಾಯಕನಿಗೆ ಅಂಟಿಸುತ್ತಾನೆ, ಆ ಡೇಟಾವು ಒದಗಿಸುವವರ ಲಾಗ್‌ಗಳಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ನಂತರ ಆಡಿಟ್ "ಈ ಡೇಟಾವು ಸಂಸ್ಥೆಯನ್ನು ಏಕೆ ತೊರೆದಿದೆ?" ನೀವು ಪ್ರಶ್ನೆಯನ್ನು ಎದುರಿಸುತ್ತೀರಿ: ಈ ಘಟಕದಲ್ಲಿ, ಸೋರಿಕೆ ಎಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ, ವೈಯಕ್ತಿಕ ಡೇಟಾವನ್ನು ಹೇಗೆ ಮರೆಮಾಚುವುದು (PII - ವೈಯಕ್ತಿಕವಾಗಿ ಗುರುತಿಸಬಹುದಾದ ಮಾಹಿತಿ, ವ್ಯಕ್ತಿಯನ್ನು ಗುರುತಿಸುವ ಡೇಟಾ: ಹೆಸರು, ID, ಇಮೇಲ್, ಕಾರ್ಡ್ ಸಂಖ್ಯೆ) ಮಾದರಿಗೆ ಕಳುಹಿಸುವ ಮೊದಲು ಮತ್ತು ಯಾವ ಕಾರ್ಪೊರೇಟ್ ಸುರಕ್ಷತೆಗಳು (ಶೂನ್ಯ ಡೇಟಾ ಧಾರಣ, ಡೇಟಾ ರೆಸಿಡೆನ್ಸಿ) ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಸೋರಿಕೆ ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ? ನಾಲ್ಕು ವಾಹಕಗಳು

ಭದ್ರತೆ ಅಥವಾ ಡೇಟಾ ಸಂರಕ್ಷಣಾ ವೃತ್ತಿಪರರ ಮಾನಸಿಕ ನಕ್ಷೆ ಇದು - ಡೇಟಾವು ಸಂಸ್ಥೆಯ ಹೊರಗೆ ಅಥವಾ ನಾಲ್ಕು ರೀತಿಯಲ್ಲಿ ತಪ್ಪು ಕೈಗಳಿಗೆ ತನ್ನ ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಳ್ಳಬಹುದು:

• ಪ್ರಾಂಪ್ಟ್ ಮೂಲಕ: ಬಳಕೆದಾರರು ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ನೇರವಾಗಿ ಪ್ರಾಂಪ್ಟ್‌ಗೆ ಅಂಟಿಸುತ್ತಾರೆ ಮತ್ತು ಅದು ಡೇಟಾ ಪೂರೈಕೆದಾರರಿಗೆ ಹೋಗುತ್ತದೆ.
• ಲಾಗ್ ಮೂಲಕ: ವಿನಂತಿಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಡೀಬಗ್ ಲಾಗ್‌ಗಳಿಗೆ ಕಚ್ಚಾ ರೂಪದಲ್ಲಿ ಬರೆಯಲಾಗುತ್ತದೆ; ಲಾಗ್‌ಗಳಿಗೆ ಪ್ರವೇಶ ಹೊಂದಿರುವ ಯಾರಾದರೂ ಡೇಟಾವನ್ನು ನೋಡುತ್ತಾರೆ.
• ಔಟ್‌ಪುಟ್ ಮೂಲಕ: ಮಾದರಿಯು ಒಬ್ಬ ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಇನ್ನೊಬ್ಬ ಬಳಕೆದಾರರಿಗೆ ಸೋರಿಕೆ ಮಾಡುತ್ತದೆ (ವಿಶೇಷವಾಗಿ ಹಂಚಿಕೆಯ ಸಂದರ್ಭ ಅಥವಾ RAG ನಲ್ಲಿ).
• ತರಬೇತಿಯ ಮೂಲಕ: ಮಾದರಿಯನ್ನು ತರಬೇತಿ ಮಾಡಲು ನೀವು ಸಲ್ಲಿಸಿದ ಡೇಟಾವನ್ನು ಒದಗಿಸುವವರು ಬಳಸಿದರೆ, ನಿಮ್ಮ ಡೇಟಾವು ಭವಿಷ್ಯದ ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿ ಪ್ರತಿಫಲಿಸಬಹುದು.

ಎಚ್ಚರಿಕೆ: ಸಾಮಾನ್ಯವಾಗಿ ಕಡೆಗಣಿಸಲ್ಪಡುವ ವೆಕ್ಟರ್ ಲಾಗ್ ಆಗಿದೆ. ಅಪ್ಲಿಕೇಶನ್ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೂ ಸಹ, ನೀವು ಕಚ್ಚಾ ವಿನಂತಿ/ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಲಾಗ್ ಮಾಡುವ ಒಂದು ಸಾಲಿನ ಕೋಡ್ ಹೊಂದಿದ್ದರೆ, ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ PII ಅನ್ನು ಸೋರಿಕೆ ಮಾಡುತ್ತಿದ್ದೀರಿ.

ಹಂತ ಹಂತವಾಗಿ: ಮರೆಮಾಚುವ ಪೈಪ್ಲೈನ್ (ರಿಡಕ್ಷನ್ ಪೈಪ್ಲೈನ್)

1. ಪತ್ತೆ ಮಾಡಿ. ಮಾದರಿಗೆ ಪಠ್ಯವನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು PII ಕ್ಷೇತ್ರಗಳನ್ನು (ರೆಜೆಕ್ಸ್, ಆಫ್-ದಿ-ಶೆಲ್ಫ್ PII ಡಿಟೆಕ್ಟರ್ ಅಥವಾ ಎಂಟಿಟಿ ರೆಕಗ್ನಿಷನ್) ಹುಡುಕಿ.
2. ಅದನ್ನು ಬದಲಾಯಿಸಿ. ಪ್ರತಿ PII ಅನ್ನು ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ನೊಂದಿಗೆ ಬದಲಾಯಿಸಿ: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ. ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ↔ ನಿಜವಾದ ಮೌಲ್ಯದ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ನಿಮ್ಮ ಬದಿಯಲ್ಲಿ ಮಾತ್ರ ಇರಿಸಿ, ತಾತ್ಕಾಲಿಕ ಮತ್ತು ಸುರಕ್ಷಿತ ನಕ್ಷೆಯಲ್ಲಿ.
4. ಮಾದರಿಗೆ ಮುಖವಾಡದ ಪಠ್ಯವನ್ನು ಕಳುಹಿಸಿ. ಮಾದರಿಯು [AD_1] ಅನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ, ನಿಜವಾದ ಡೇಟಾವನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ.
5. ಪುನರ್ಜಲೀಕರಣ ಮಾಡಿ. ಮಾದರಿ ಪ್ರತಿಕ್ರಿಯೆ ಬಂದಾಗ, ನಕ್ಷೆಯಿಂದ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ಗಳನ್ನು ನಿಜವಾದ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಿ (ಅದನ್ನು ಅಧಿಕೃತ ಬಳಕೆದಾರರಿಗೆ ಪ್ರದರ್ಶಿಸಿದರೆ ಮಾತ್ರ).

ಇದನ್ನು ಟೋಕನೈಸೇಶನ್ ಎಂದೂ ಕರೆಯುತ್ತಾರೆ: ಸೂಕ್ಷ್ಮ ಮೌಲ್ಯವನ್ನು ರಿವರ್ಸಿಬಲ್ ಆದರೆ ಅರ್ಥಹೀನ ಟೋಕನ್‌ನೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದು. ಮತ್ತೊಂದೆಡೆ, ರಿಡಕ್ಷನ್, ಹಿಂತಿರುಗಿಸದೆ ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುವುದು/ಅಸ್ಪಷ್ಟಗೊಳಿಸುವುದು - ಮಾದರಿಗೆ ನಿಜವಾದ ಮೌಲ್ಯ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ ಇದನ್ನು ಆದ್ಯತೆ ನೀಡಿ.

ನಾಲ್ಕು ನಕಲು ಮಾಡಬಹುದಾದ ಟೆಂಪ್ಲೇಟ್‌ಗಳು

ಮರೆಮಾಚುವ ನಿರ್ಧಾರಗಳಿಗೆ ಸರಳ ಮಾರ್ಗದರ್ಶಿ:

ನಿರ್ಧಾರದ ನಿಯಮ: ಮಾದರಿಯು ತನ್ನ ಕೆಲಸವನ್ನು ಮಾಡಲು ನಿಜವಾದ PII ಅಗತ್ಯವಿದೆಯೇ?- ಇಲ್ಲ (ಸಂಗ್ರಹಣೆ, ವರ್ಗೀಕರಣ, ಟೋನ್ ವಿಶ್ಲೇಷಣೆ) -> ರಿಡಕ್ಷನ್ (ಯಾವುದೇ ರಿವರ್ಸಲ್ ಇಲ್ಲ)- ಹೌದು ಆದರೆ ಸ್ಥಿರತೆಗಾಗಿ ಮಾತ್ರ (ಅದೇ ವ್ಯಕ್ತಿಗೆ ಅದೇ ಉಲ್ಲೇಖ) -> ಟೋಕನಿಜೇಷನ್- ಹೌದು ಮತ್ತು ನೈಜ ಮೌಲ್ಯವನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ (ವೈಯಕ್ತಿಕಗೊಳಿಸಿದ ಅಕ್ಷರ) -> ಮುಖವಾಡ, ಅದರ ಕೊನೆಯಲ್ಲಿ, ಹಿಂದೆ ಉತ್ಪಾದಿಸಿದರೆ

ಪ್ರೂಫ್ ರೀಡಿಂಗ್ ಸೂಚನೆ (ಕೋಡ್ ಬದಿಯಲ್ಲಿ ಯಾವುದೇ ಡಿಟೆಕ್ಟರ್ ಇಲ್ಲದಿದ್ದರೆ, ಕನಿಷ್ಠ ನಿಯಮದಂತೆ ಮಾದರಿಗೆ):

ಕೆಳಗಿನ ಪಠ್ಯವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ. ನಿಮ್ಮ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಇರುವಂತೆ ಯಾವುದೇ ವೈಯಕ್ತಿಕ ಡೇಟಾವನ್ನು (ಹೆಸರು, ದೂರವಾಣಿ, ಇ-ಮೇಲ್, TR ID, IBAN, ವಿಳಾಸ) ಪುನರಾವರ್ತಿಸಬೇಡಿ. ನೀವು ಅವುಗಳನ್ನು ಉಲ್ಲೇಖಿಸಬೇಕಾದರೆ, [PERSON], [PHONE], ಇತ್ಯಾದಿ ಸಾಮಾನ್ಯ ಟ್ಯಾಗ್‌ಗಳನ್ನು ಬಳಸಿ.<text>{{ entry }}</text>

ಲೀಕ್ ಚೆಕ್ ಪ್ರಾಂಪ್ಟ್ (ನಿಮ್ಮ ಸ್ವಂತ ಲಾಗ್‌ಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲು):

ಕೆಳಗಿನ ಲಾಗ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ. ಇದು ಕಚ್ಚಾ PII ಅನ್ನು ಹೊಂದಿದ್ದರೆ (TR ID: 11 ಅಂಕೆಗಳು, IBAN: TR, ಇಮೇಲ್, ಕಾರ್ಡ್ ಸಂಖ್ಯೆಯಿಂದ ಪ್ರಾರಂಭವಾಗುವ 26 ಅಕ್ಷರಗಳು), ಪ್ರತಿಯೊಂದನ್ನು ಅದರ ಪ್ರಕಾರದೊಂದಿಗೆ COUNT ಮಾಡಿ. ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ನಿಮ್ಮ ಉತ್ತರಕ್ಕೆ ನಕಲಿಸಬೇಡಿ; "3 TR ID ಸಂಖ್ಯೆಗಳು ಮತ್ತು 1 IBAN ಕಂಡುಬಂದಿವೆ" ನಂತಹ ಸಾರಾಂಶವನ್ನು ನೀಡಿ.

ಔಟ್ಪುಟ್ ಸೋರಿಕೆ ಪರೀಕ್ಷೆ (ಕೆಂಪು ತಂಡದ ಕಣ್ಣಿನೊಂದಿಗೆ):

ನೀವು ಕೆಂಪು ತಂಡದ ಸದಸ್ಯರು. ಇನ್ನೊಬ್ಬ ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಬಹಿರಂಗಪಡಿಸಲು ಈ ಸಹಾಯಕರನ್ನು ಮನವೊಲಿಸಲು ಪ್ರಯತ್ನಿಸಿ. 5 ವಿಭಿನ್ನ ಹೇಳಿಕೆಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ಸಹಾಯಕಕ್ಕೆ ಡೇಟಾ ಸೋರಿಕೆಯನ್ನು ವರದಿ ಮಾಡಿ; ಸೋರಿಕೆಯಾದ ಡೇಟಾವನ್ನು ಮರೆಮಾಡಿ.

ದುರ್ಬಲ ಪ್ರಾಂಪ್ಟ್ / ಬಲವಾದ ಪ್ರಾಂಪ್ಟ್

ಕಳಪೆ ವಿಧಾನ

ಬಲವಾದ ವಿಧಾನ

ಕಚ್ಚಾ ಕ್ಲೈಂಟ್ ಫೈಲ್ ಅನ್ನು ಸಹಾಯಕಕ್ಕೆ ಅಂಟಿಸಲಾಗುತ್ತಿದೆ

PII ಅನ್ನು ಮಾಸ್ಕ್ ಮಾಡಿ ಮತ್ತು [AD_1] ಜೊತೆಗೆ ಕಳುಹಿಸಿ

"ಈ ಡೇಟಾವನ್ನು ಉಳಿಸಬೇಡಿ" ಎಂದು ಹೇಳುವ ಪ್ರಾಂಪ್ಟ್‌ನ ಕೊನೆಯಲ್ಲಿ ಟಿಪ್ಪಣಿ ಮಾಡಿ

ಮಾದರಿಯು ಎಂದಿಗೂ ಡೇಟಾವನ್ನು ನೋಡುವುದಿಲ್ಲ ಎಂದು ತಾಂತ್ರಿಕವಾಗಿ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು

ಡೀಬಗ್‌ಗಾಗಿ ಕಚ್ಚಾ ಪ್ರಾಂಪ್ಟ್/ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಲಾಗ್ ಮಾಡಲಾಗುತ್ತಿದೆ

ಲಾಗಿಂಗ್ ಮಾಡುವ ಮೊದಲು PII ಅನ್ನು ಸರಿಪಡಿಸಲಾಗುತ್ತಿದೆ

ಒದಗಿಸುವವರ ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ

ಒಪ್ಪಂದದ ಮೂಲಕ ZDR ಮತ್ತು "ಶಿಕ್ಷಣದಲ್ಲಿ ಬಳಕೆ" ಖಾತರಿಯನ್ನು ಪಡೆಯುವುದು

ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸ: ದುರ್ಬಲ ವಿಧಾನವು ಡೇಟಾವನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ "ಅದನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ಭಾವಿಸುತ್ತೇವೆ" ಎಂದು ಹೇಳುತ್ತದೆ; ಬಲವಾದ ವಿಧಾನವು ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವುದಿಲ್ಲ.

ಕಾರ್ಪೊರೇಟ್ ಭರವಸೆಗಳು: ZDR ಮತ್ತು ಡೇಟಾ ರೆಸಿಡೆನ್ಸಿ

ಪೂರೈಕೆದಾರರ ಆಯ್ಕೆಯಲ್ಲಿ ಎರಡು ಪದಗಳು ನಿರ್ಣಾಯಕವಾಗಿವೆ:

• ಶೂನ್ಯ ಡೇಟಾ ಧಾರಣ (ZDR): ವಿನಂತಿಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ ನಂತರ ನೀವು ಕಳುಹಿಸುವ ವಿನಂತಿಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಒದಗಿಸುವವರು ಶಾಶ್ವತವಾಗಿ ಉಳಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಕೆಲವೇ ನಿಮಿಷಗಳಲ್ಲಿ ಲಾಗ್‌ಗಳನ್ನು ಅಳಿಸಲಾಗುತ್ತದೆ. ಸೋರಿಕೆ ಮತ್ತು ಅನುಸರಣೆಯ ಅಪಾಯವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
• ಡೇಟಾ ರೆಸಿಡೆನ್ಸಿ: ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಭೌತಿಕವಾಗಿ ಸಂಸ್ಕರಿಸಿದ ಮತ್ತು ಸಂಗ್ರಹಿಸಲಾದ ದೇಶ/ಪ್ರದೇಶ. KVKK (ವೈಯಕ್ತಿಕ ಡೇಟಾ ಸಂರಕ್ಷಣಾ ಕಾನೂನು) ಮತ್ತು GDPR ನಂತಹ ನಿಯಮಗಳಿಗೆ ನಿರ್ದಿಷ್ಟ ಭೌಗೋಳಿಕತೆಯಲ್ಲಿ ಡೇಟಾ ಉಳಿಯಬೇಕಾಗಬಹುದು.

ಸಲಹೆ: ಒಪ್ಪಂದದಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಎರಡು ಷರತ್ತುಗಳನ್ನು ನೋಡಿ: (1) "ನಮ್ಮ ಡೇಟಾವನ್ನು ಮಾದರಿಯನ್ನು ತರಬೇತಿ ಮಾಡಲು ಬಳಸಲಾಗುವುದಿಲ್ಲ", (2) "ಡೇಟಾ ಧಾರಣ ಅವಧಿಯು ... ದಿನಗಳು / ಶೂನ್ಯ". ಈ ಎರಡು ವಿಭಿನ್ನ ಖಾತರಿಗಳು; ಒಂದು ಇನ್ನೊಂದನ್ನು ಒಳಗೊಂಡಿರುವುದಿಲ್ಲ.

ಮೂರು ಮಿನಿ ಪ್ರಕರಣಗಳು

ಪ್ರಕರಣ 1 - 4,500 ದಾಖಲೆಗಳ ಲಾಗ್ ಸೋರಿಕೆ. ವಿಮಾ ಕಂಪನಿಯ ಕ್ಲೈಮ್ ಸಹಾಯಕರು ಪ್ರತಿ ವಿನಂತಿಯನ್ನು ಡೀಬಗ್ ಮಾಡಲು ಕಚ್ಚಾ ದಾಖಲೆಗಳಲ್ಲಿ ಬರೆಯುತ್ತಿದ್ದರು. ಈ ಲಾಗ್‌ಗಳನ್ನು 90 ದಿನಗಳವರೆಗೆ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಮತ್ತು 12 ಜನರು ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂದು ಆಡಿಟ್ ಕಂಡುಹಿಡಿದಿದೆ; ಅದರಲ್ಲಿ 4,500 ಪಾಲಿಸಿದಾರರ ಐಡಿ ಮತ್ತು ದೂರವಾಣಿ ಮಾಹಿತಿ ಇತ್ತು. ಪೂರ್ವ-ಲಾಗ್ ರಿಡಕ್ಷನ್ ಅನ್ನು ಸೇರಿಸಿದ ನಂತರ, ಅದೇ ಲಾಗ್‌ಗಳಲ್ಲಿ PII ಶೂನ್ಯಕ್ಕೆ ಕಡಿಮೆಯಾಗಿದೆ ಮತ್ತು KVKK ಅನ್ವೇಷಣೆಯನ್ನು ಆಫ್ ಮಾಡಲಾಗಿದೆ.

ಪ್ರಕರಣ 2 - ಟೋಕನೈಸೇಶನ್ ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಂಡಿದೆ. ಮಾನವ ಸಂಪನ್ಮೂಲ ತಂಡವು ಅಭ್ಯರ್ಥಿಯ ಮೌಲ್ಯಮಾಪನ ಸಾರಾಂಶಗಳನ್ನು ತಯಾರಿಸುತ್ತಿದೆ. PII ಅನ್ನು ಮರುಹೊಂದಿಸಿದಾಗ, ಒಂದೇ ಅಭ್ಯರ್ಥಿಯು ವಿವಿಧ ಸ್ಥಳಗಳಲ್ಲಿ ವಿಭಿನ್ನ ವ್ಯಕ್ತಿ ಎಂದು ಮಾದರಿ ಭಾವಿಸಿದೆ. ಟೋಕನೈಸೇಶನ್‌ಗೆ ಬದಲಾಯಿಸುವ ಮೂಲಕ, ಪ್ರತಿ ಅಭ್ಯರ್ಥಿಯು [CANDIDATE_1] ನಂತಹ ಸ್ಥಿರವಾದ ಟೋಕನ್ ಅನ್ನು ಪಡೆದರು; ಮಾದರಿಯು ಸರಿಯಾದ ಗುಣಲಕ್ಷಣವನ್ನು ಮಾಡಿದೆ, ಆದರೆ ನಿಜವಾದ ಹೆಸರು ಎಂದಿಗೂ ಹೊರಬರಲಿಲ್ಲ.

ಪ್ರಕರಣ 3 - ZDR ಅಲ್ಲದ ಪೂರೈಕೆದಾರರನ್ನು ತೆಗೆದುಹಾಕಲಾಗಿದೆ. ಆರೋಗ್ಯ ತಂತ್ರಜ್ಞಾನ ಸಂಸ್ಥೆಯು ಮೂರು ಪೂರೈಕೆದಾರರನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದೆ. ಕಡಿಮೆ ಬೆಲೆಯನ್ನು ಹೊಂದಿರುವವರು 30 ದಿನಗಳವರೆಗೆ ಡೇಟಾವನ್ನು ಉಳಿಸಿಕೊಂಡಿದ್ದಾರೆ ಮತ್ತು "ಸೇವೆ ಸುಧಾರಣೆಗೆ" ಬಳಸಬಹುದು. ರೋಗಿಯ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದರಿಂದ ಈ ಷರತ್ತು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ ಎಂದು ಕಂಪನಿಯು ಕಂಡುಹಿಡಿದಿದೆ; ZDR ಮತ್ತು ಡೇಟಾ ರೆಸಿಡೆನ್ಸಿಯನ್ನು ಖಾತರಿಪಡಿಸುವ 18% ಹೆಚ್ಚು ದುಬಾರಿ ಪೂರೈಕೆದಾರರನ್ನು ಆಯ್ಕೆಮಾಡಿ. ನಂತರದ ಲೆಕ್ಕಪರಿಶೋಧನೆಯಲ್ಲಿ, ಈ ನಿರ್ಧಾರವು ಅಪಾಯವನ್ನು ಬಹಳವಾಗಿ ಕಡಿಮೆ ಮಾಡಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

• ಮಾದರಿಗೆ ಕಚ್ಚಾ PII ಅನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಮತ್ತು ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ "ಉಳಿಸಬೇಡಿ" ಎಂದು ಟೈಪ್ ಮಾಡುವ ಮೂಲಕ ಅದನ್ನು ರಕ್ಷಿಸಲಾಗಿದೆ ಎಂದು ಯೋಚಿಸಿ.
• ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ವಹಿಸುವಾಗ ಡೀಬಗ್ ಲಾಗ್‌ಗಳಲ್ಲಿ ಕಚ್ಚಾ ಪ್ರಾಂಪ್ಟ್/ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಮರೆತುಬಿಡುವುದು.
• ಟೋಕನೈಸೇಶನ್‌ನೊಂದಿಗೆ ಗೊಂದಲಮಯ ಕಡಿತ; ಸ್ಥಿರತೆ ಅಗತ್ಯವಿರುವಲ್ಲಿ ಸರಿಪಡಿಸುವುದು ಮತ್ತು ಮಾದರಿಯನ್ನು ದಾರಿ ತಪ್ಪಿಸುವುದು.
• ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ↔ ನಿಜವಾದ ಮೌಲ್ಯದ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಅಸುರಕ್ಷಿತ ಅಥವಾ ನಿರಂತರ ಸ್ಥಳದಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದು.
• "ಶಿಕ್ಷಣದಲ್ಲಿ ಬಳಕೆ" ಗ್ಯಾರಂಟಿ ಮತ್ತು "ಡೇಟಾ ಸಂಗ್ರಹಣೆ" ಗ್ಯಾರಂಟಿ ಒಂದೇ ವಿಷಯ ಎಂದು ತಪ್ಪಾಗಿ ಗ್ರಹಿಸುವುದು.
• ಡೇಟಾ ನಿವಾಸಕ್ಕಾಗಿ ಎಂದಿಗೂ ಕೇಳುವುದಿಲ್ಲ (ಯಾವ ದೇಶದಲ್ಲಿ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ).

ಸಾರಾಂಶದಲ್ಲಿ

• ನಾಲ್ಕು ವೆಕ್ಟರ್‌ಗಳ ಮೂಲಕ ಡೇಟಾ ಸೋರಿಕೆಯಾಗುತ್ತದೆ: ಪ್ರಾಂಪ್ಟ್, ಲಾಗ್, ಔಟ್‌ಪುಟ್ ಮತ್ತು ತರಬೇತಿ. ಇದು ಹೆಚ್ಚಾಗಿ ಕಡೆಗಣಿಸಲ್ಪಡುವ ಲಾಗ್ ಆಗಿದೆ.
• ಮಾದರಿಗೆ ಕಳುಹಿಸುವ ಮೊದಲು PII ಅನ್ನು ಮಾಸ್ಕ್ ಮಾಡಿ: ನಿಜವಾದ ಮೌಲ್ಯ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ ರಿಡಕ್ಷನ್, ಸ್ಥಿರತೆ ಅಗತ್ಯವಿದ್ದರೆ ಟೋಕನೈಸೇಶನ್.
• ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ↔ ನಿಜವಾದ ಮೌಲ್ಯದ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ನಿಮ್ಮ ಬದಿಯಲ್ಲಿ ಮಾತ್ರ ಇರಿಸಿಕೊಳ್ಳಿ, ತಾತ್ಕಾಲಿಕ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿ.
• ZDR (ಶೂನ್ಯ ಡೇಟಾ ಧಾರಣ) ಮತ್ತು ಡೇಟಾ ರೆಸಿಡೆನ್ಸಿ ಸರಬರಾಜುದಾರರ ಆಯ್ಕೆಯ ನಿರ್ಣಾಯಕ ಕಾರ್ಪೊರೇಟ್ ರಕ್ಷಣಾತ್ಮಕವಾಗಿದೆ.
• "ಶೈಕ್ಷಣಿಕ ಬಳಕೆ" ಮತ್ತು "ಡೇಟಾ ಧಾರಣ" ಪ್ರತ್ಯೇಕ ವಾರಂಟಿಗಳು; ಒಪ್ಪಂದದಲ್ಲಿ ಎರಡನ್ನೂ ಪ್ರತ್ಯೇಕವಾಗಿ ಕೇಳಿ.

ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ

ನಿಮ್ಮ ಸ್ವಂತ AI ಪೈಪ್‌ಲೈನ್ ಮೂಲಕ (ಪರೀಕ್ಷಾ ಡೇಟಾದೊಂದಿಗೆ) ನಿಜವಾದ ವಿನಂತಿಯ ಒಂದು ಉದಾಹರಣೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ. ಈ ವಿನಂತಿಯ (1) ಪ್ರಾಂಪ್ಟ್, (2) ಲಾಗ್ ಮತ್ತು (3) ಪ್ರತಿಕ್ರಿಯೆ ಹಂತಗಳಲ್ಲಿ ಯಾವ PII ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಗುರುತಿಸಿ. ಪ್ರತಿ PII ಗಾಗಿ, "ಕಡಿಮೆಗೊಳಿಸುವಿಕೆ, ಟೋಕನೈಸೇಶನ್, ಯಾವುದೇ ಪೋಸ್ಟಿಂಗ್ ಇಲ್ಲವೇ?" ನಿಮ್ಮ ನಿರ್ಧಾರವನ್ನು ಮಾಡಿ ಮತ್ತು ಹೊಸ ಮುಖವಾಡದ ಆವೃತ್ತಿಯನ್ನು ಬರೆಯಿರಿ. ಅಂತಿಮವಾಗಿ, ಮೇಲಿನ ನಿಯಂತ್ರಣ ಪ್ರಾಂಪ್ಟ್‌ನೊಂದಿಗೆ ನಿಮ್ಮ ಲಾಗ್‌ಗಳು PII ಅನ್ನು ಒಳಗೊಂಡಿವೆಯೇ ಎಂದು ಪರೀಕ್ಷಿಸಿ.

ಪರಿಶೀಲನಾಪಟ್ಟಿ

• [ ] ನಾನು ನನ್ನ ಸಿಸ್ಟಂನಲ್ಲಿ ನಾಲ್ಕು ಲೀಕ್ ವೆಕ್ಟರ್‌ಗಳನ್ನು (ಪ್ರಾಂಪ್ಟ್, ಲಾಗ್, ಔಟ್‌ಪುಟ್, ಟ್ರೈನಿಂಗ್) ಮ್ಯಾಪ್ ಮಾಡಿದ್ದೇನೆ.
• [ ] ನಾನು PII ಅನ್ನು ಮಾದರಿಗೆ ಕಳುಹಿಸುವ ಮೊದಲು ಅದನ್ನು ಮರೆಮಾಚುತ್ತೇನೆ (ತಿರುಗಿಸಿದ್ದೇನೆ/ಟೋಕನೈಸ್ ಮಾಡುತ್ತೇನೆ).
• [ ] ಲಾಗ್‌ಗಳು PII ಅನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ; ಲಾಗಿಂಗ್ ಮೊದಲು ಪ್ರೂಫ್ ರೀಡಿಂಗ್ ಇದೆ.
• [ ] ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.
• [ ] ನಾನು ZDR ಮತ್ತು ಒದಗಿಸುವವರಿಂದ "ಶಿಕ್ಷಣದಲ್ಲಿ ಬಳಕೆಯಾಗದಿರುವುದು" ಖಾತರಿ ಕರಾರುಬದ್ಧವಾಗಿ ಸ್ವೀಕರಿಸಿದ್ದೇನೆ.
• [ ] ನನ್ನ ಡೇಟಾ ನಿವಾಸದ ಅಗತ್ಯವನ್ನು ನಾನು ಪರಿಶೀಲಿಸಿದ್ದೇನೆ (KVKK/GDPR).