גילוי דעת: משתמשים ב-AI דרך ספק חיצוני? כדאי לדעת מה קורה למידע ולזכויות שלכם
מערכות AI ייעודיות לעורכי דין אינן בדרך כלל "מודל AI" בפני עצמן. ברוב המקרים, החברה שמספקת לכם את השירות בונה מערכת מעל מודל של ספק גדול, כמו OpenAI, Google או Anthropic. החיבור נעשה בדרך כלל באמצעות API, ממשק תוכנה שמאפשר למערכת של הספק לשלוח בקשות למודל ולקבל ממנו תשובות באופן אוטומטי. מעל המודל מוסיפה החברה את הערך שלה: ממשק משפטי, העלאת מסמכים, OCR (זיהוי והמרת טקסט מתוך מסמכים סרוקים), מאגרי פסיקה, RAG (מנגנון שמאתר חומר רלוונטי מתוך מאגר ומצרף אותו לבקשה שנשלחת למודל), זיכרון של תיק, הרשאות, תבניות ולעיתים גם חיבור למערכות המשרד. זו ארכיטקטורה מקובלת ולגיטימית, ולעיתים היא מאפשרת לבנות כלים משפטיים מצוינים. אבל יש לה משמעות שחשוב להבין כבר בתחילת הדרך: המידע שאתם מעלים אינו בהכרח עובר ישירות מהמחשב שלכם אל מודל ה-AI וחזרה. החומר עשוי לעבור דרך המערכת של הספק, ספק ענן, שירות OCR, מסד נתונים וקטורי (מאגר שמאפשר לחפש מידע לפי קרבה במשמעות ולא רק לפי מילים זהות), מערכות לוגים (תיעוד טכני של פעולות ובקשות), מערכות ניטור, ספק המודל וספקי משנה נוספים. וכאן הדיון כבר אינו רק טכנולוגי. אם אתם מעבירים בדרך הזאת מידע אישי ממאגר שבאחריותכם, הדין בישראל מטיל חובות ביחס להתקשרות עם גורם חיצוני שמעבד את המידע. תקנה 15 לתקנות הגנת הפרטיות (אבטחת מידע) מחייבת, בין היתר, לבחון את הסיכונים שבהתקשרות עם ספק חיצוני, להסדיר את חובותיו ולפקח על עמידתו בהן. הרשות להגנת הפרטיות מבהירה במדריך המעודכן שלה כי עוד לפני ההתקשרות צריך לבחון אם הסיכונים הכרוכים בה מאפשרים בכלל להתקשר עם הספק. לכן, אם אתם עומדים להעלות למערכת חומר של לקוחות והספק אינו מסוגל לתת לכם תשובות כתובות ומסודרות לגבי עיבוד המידע, שמירתו, השימוש בו והגורמים שנחשפים אליו, זו אינה רק אי-נוחות. קשה לדעת במצב כזה אם ביצעתם את הבדיקה שנדרשת מכם לפני מסירת המידע לגורם חיצוני. כשמדובר במידע אישי, חסוי או רגיש, נוצר ספק ממשי אם נכון ומותר להעביר אותו למערכת לפני שהנושאים האלה הוסדרו. השאלה "באיזה מודל אתם משתמשים?" פשוט אינה מספיקה.
אותו מודל אינו אומר אותו מידע
חשוב גם לא לייצר חשש במקום שבו אין צורך. אם שני עורכי דין משתמשים באותה מערכת, ואפילו אם הפעילות של שניהם עוברת דרך אותו חשבון API של ספק המערכת, אין פירוש הדבר שהמודל עצמו מערבב ביניהם. נניח שאתם מייצגים תובע. העליתם למערכת את חומר התיק והיא התריעה שמסמך מסוים מחליש את התביעה, שפסק דין שתכננתם להסתמך עליו עשוי דווקא לסייע לנתבע ושקיימת סתירה בגרסת הלקוח. כעבור שבוע עורך הדין של הנתבע משתמש באותה מערכת ומבקש לנתח את כתב התביעה. במערכת שתוכננה כראוי, המידע שנמסר במסגרת העבודה שלכם אינו אמור להיות זמין לו. המודל אינו אמור "לזכור" שפגש קודם את הצד השני ולשלוף עבורו את סודות התיק. הסיכון העיקרי נמצא בשכבות שהספק בנה סביב המודל.
הבעיה אינה שהמודל זוכר, אלא שהמערכת עלולה להזכיר לו
מערכות AI מקצועיות אינן שולחות בהכרח למודל רק את השאלה שהקלדתם. לעיתים הן מחפשות קודם במסמכים, שולפות קטעים רלוונטיים, מצרפות תקצירים משיחות קודמות ומוסיפות חומר מתוך מאגר הידע. זה בדיוק אחד התפקידים של RAG: לאפשר למודל לעבוד עם חומר שלא נמצא בתוך הידע המקורי שלו, באמצעות שליפתו ממאגר בזמן השאלה. לצורך השליפה הזאת משתמשים לא פעם ב-embeddings, ייצוגים מספריים של טקסט שמאפשרים למערכת למדוד עד כמה שני קטעים קרובים זה לזה מבחינת משמעות. כאשר ההפרדה בין לקוחות ותיקים בנויה נכון, זו יכולת מצוינת. כאשר היא אינה בנויה נכון, מנגנון השליפה עלול להביא חומר מתיק אחר או מלקוח אחר ולהכניס אותו לבקשה הנוכחית. במקרה כזה המודל לא "זכר" מידע חסוי. המערכת של הספק מסרה לו אותו. לכן בידוד בין לקוחות, בין תיקים ובין משתמשים אינו פרט טכני שולי. הוא אחת השאלות הראשונות שצריכות לעניין אתכם.
"המערכת מאובטחת" אינה תשובה
הספק אינו צריך למסור לכם קוד מקור, תרשים רשת מלא או פרטים שעלולים לפגוע באבטחת המערכת. סודות מסחריים נשארים סודות מסחריים. אבל הוא כן צריך להיות מסוגל להסביר, ברמה שמאפשרת לכם להעריך את הסיכון, כיצד מופרדים לקוחות ותיקים, כיצד נאכפות הרשאות בזמן חיפוש ושליפה, כיצד מופרדים מסמכים, embeddings, זיכרון והיסטוריית שיחות, ומה מונע זליגה בין סביבות. צריך לשאול גם על cache, כלומר מטמון שבו נשמרים לעיתים עותקים זמניים של מידע כדי לזרז פעולות חוזרות. "המידע מוצפן", "אנחנו עומדים בתקנים" או "אנחנו משתמשים ב-OpenAI Enterprise" אינם מענה לשאלת הבידוד. אתם לא צריכים לדעת כיצד הקוד נכתב. אתם כן צריכים לדעת מה המערכת מתחייבת למנוע.
אין התחייבות שלא מאמנים על המידע? זו בעיה אמיתית
בנקודה הזאת לא כדאי להסתפק בניסוחים עמומים. אם אתם מוסרים חומר של לקוח, אתם צריכים לקבל התחייבות ברורה לגבי השימוש בו לצורכי אימון ושיפור מערכות. ולא רק לגבי הקבצים שהעליתם. גם הפרומפט הוא מידע. פרומפט, כלומר ההוראה, השאלה או התיאור שאתם מזינים למערכת, יכול לכלול שם של לקוח, תיאור של אירוע, אסטרטגיה משפטית, נקודת חולשה בתיק, תוכן של שיחה חסויה או הנחיה שממנה ניתן ללמוד הרבה מאוד על הלקוח, גם אם לא צורף אליה מסמך אחד. כך גם התוצר שהמערכת יצרה והמשוב שנתתם עליה. לכן אם תנאי השירות מאפשרים לספק להשתמש במסמכים, בפרומפטים, בקלט, בפלט, בתיקונים או במשוב לצורך אימון מודלים, fine-tuning (אימון המשך של מודל על חומר ייעודי) או שיפור כללי של המערכת מעבר למתן השירות עבורכם, יש כאן בעיה מהותית שצריך לפתור לפני שמעבירים חומר של לקוחות. הרשות להגנת הפרטיות מתייחסת במפורש גם למידע שמוזן בתוך פרומפטים ומזהירה כי מידע אישי שנשמר במערכת או משמש לאימון ולשיפור האלגוריתם עלול להשפיע על תוצרים שיופקו למשתמשים אחרים. אל תסתפקו לכן במשפט "אנחנו לא מאמנים את OpenAI על המסמכים שלכם". צריך לשאול את כל השרשרת: האם אתם, ספק המודל או ספק משנה כלשהו רשאים להשתמש במשהו שאני מזין או מקבל לצורך אימון או שיפור שאינו נדרש למתן השירות שלי? אם אין על כך תשובה ברורה והתחייבות כתובה, אל תניחו שהתשובה היא לא.
זכויות היוצרים לא נעלמות כשנכנסים ל-AI
יש עוד שאלה חשובה שלא נכון להשאיר מחוץ לדיון הזה: למי שייכות הזכויות בתוכן שנכנס למערכת ובתוכן שיוצא ממנה. כתבי טענות, חוות דעת, הסכמים ומסמכים משפטיים עשויים להיות יצירות ספרותיות מוגנות בזכות יוצרים כאשר מתקיימת בהם דרישת המקוריות. הפסיקה בישראל כבר הכירה עקרונית גם בזכויות יוצרים בכתבי טענות, אם כי ההגנה אינה חלה באופן אוטומטי על כל משפט, נוסח שבלוני, הוראת חוק או טענה משפטית מקובלת. לכן כאשר אתם מעלים למערכת כתב טענות שכתבתם, אינכם מעלים רק "מידע". אתם עשויים להעביר גם יצירה שיש בה זכויות קניין רוחני. כאן צריך לשאול שתי שאלות שונות. הראשונה היא מה רשאי הספק לעשות עם היצירה שלכם. תנאי השירות צריכים להבהיר שהעלאת המסמך אינה מעניקה לספק רישיון רחב להשתמש בו לצרכים אחרים, להפיץ אותו, לשלב אותו במוצריו או לנצל אותו מעבר למה שנדרש לצורך מתן השירות. השאלה השנייה מורכבת יותר: למי שייך הפלט שהמערכת יצרה עבורכם? אסור להניח שהתשובה היא "לנו" רק מפני שאנחנו שילמנו עבור השירות. במערכת שבה אתם עובדים יש לפחות שתי מערכות חוזיות שונות: החוזה בין ספק המערכת לבין ספק המודל, והחוזה ביניכם לבין ספק המערכת. OpenAI, לדוגמה, קובעת כיום בהסכם העסקי שלה כי ביחסים בינה לבין הלקוח שלה, הלקוח שומר על זכויותיו בקלט והיא ממחה לו את זכויותיה, ככל שקיימות, בפלט. אלא שבמערכת צד שלישי "הלקוח" של OpenAI עשוי להיות דווקא החברה שמפעילה את השירות שבו אתם משתמשים. לכן צריך לבדוק מה אותה חברה מתחייבת להעביר לכם בתנאי השירות שלה. ויש כאן שכבה נוספת: תנאי שימוש יכולים להסדיר בעלות חוזית בין הצדדים, אבל הם אינם יכולים להבטיח שבכל פלט AI קיימת מלכתחילה זכות יוצרים לפי הדין. חוק זכות יוצרים הישראלי מגן על יצירה מקורית וקובע ככלל שהיוצר הוא הבעלים הראשון של זכות היוצרים. השאלה כיצד הכללים האלה חלים על טקסט שנוצר באופן אוטונומי במידה רבה בידי מערכת AI עדיין אינה מוסדרת בישראל באופן חד וברור. ככל שאתם עצמכם מעצבים את הטיעון, בוחרים את המבנה, עורכים את הנוסח, מוסיפים ניתוח משפטי ומבצעים עבודה יצירתית ממשית, קל יותר לזהות בתוך התוצר תרומה אנושית מקורית שעשויה להיות מוגנת. אבל לא נכון להבטיח מראש שכל טקסט גולמי שהמערכת הפיקה עבורכם יהיה יצירה מוגנת בזכות יוצרים שניתן לאכוף כלפי העולם. לכן לפני שאתם משתמשים במערכת שמנסחת כתבי טענות, חוזים או חוות דעת, בקשו תשובה כתובה גם לשאלה הזאת: אילו זכויות מעניק לכם הספק בפלט, אילו זכויות הוא שומר לעצמו, והאם הוא רשאי להשתמש בפלט שלכם עבור משתמשים אחרים או לצרכים אחרים.
וגם "לא משמש לאימון" עדיין לא פותר הכול
גם התחייבות מלאה שלא להשתמש במידע לאימון אינה מסיימת את הבדיקה. מידע יכול שלא לשמש לאימון ועדיין להישמר בלוגים, במסד וקטורי, בהיסטוריית שיחה, במערכת ניטור או בגיבויים. הוא יכול להיות נגיש לעובד תמיכה במקרה של תקלה או לעבור לספק משנה. לכן מדובר בשאלות שונות: האם משתמשים במידע לאימון או לשיפור; כמה זמן הוא נשמר; מי רשאי לגשת אליו; ואילו זכויות שימוש נשארות בידי הספק. צריך לקבל תשובה לכל אחת מהן.
מי יכול לראות את החומר שלכם
מאחורי כל מערכת יש גם בני אדם. מפתחים, אנשי DevOps (אנשי תשתיות ותפעול שאחראים על הפעלת המערכות), אנשי תמיכה, אנשי QA (בדיקות איכות) ולעיתים קבלני משנה. אין סיבה להניח שעובדי ספק AI יושבים וקוראים מסמכים של לקוחות. השאלה היא אחרת: האם מבחינה טכנית וארגונית הם יכולים לגשת אליהם, באילו נסיבות, מי מאשר את הגישה, האם היא מתועדת וכיצד היא מוגבלת. כשמדובר בחיסיון, במידע רפואי, בסודות מסחריים או באסטרטגיית ליטיגציה, זו אינה שאלה שולית.
"מערכת סגורה" אינה בהכרח מערכת מבודדת
מערכת יכולה להיות "סגורה" לציבור ובכל זאת לשרת מאות משרדים באותה תשתית. היא יכולה להיות מוגנת בסיסמה ועדיין לא ליישם הפרדה מספקת בין תיקים. לכן כשאומרים לכם "סביבה סגורה", שאלו: סגורה בפני מי, ומבודדת ממה? הדבר נכון גם בתוך המשרד שלכם. אם משתמש מסוים אינו מורשה לפתוח תיק במערכת ניהול המסמכים, הוא גם לא אמור לקבל מידע מאותו תיק דרך ה-AI. מערכת שמתחברת למידע הארגוני צריכה לכבד את ההרשאות הקיימות, לא להפוך את כל הידע של המשרד למאגר אחד פתוח בפני כל מי שיודע לשאול את השאלה הנכונה.
מה באמת נמחק כשלוחצים "מחק"
מסמך שעולה למערכת AI עשוי להפוך לכמה רכיבים: הקובץ המקורי, הטקסט שחולץ ממנו, embeddings, קטעים לצורך חיפוש, תקצירים, היסטוריית שיחות, cache וגיבויים. לכן ראוי לדעת מה קורה כאשר מוחקים אותו. מה נמחק מיד, מה נמחק מאוחר יותר, מה נשאר בגיבויים ולכמה זמן. אין סיבה להניח שספק מבצע "מחיקה למראית עין". אפשר בהחלט לבנות מנגנון מחיקה תקין. אבל אתם צריכים לדעת מה המדיניות שלו בפועל.
הספק שלכם אינו בהכרח הספק היחיד
מאחורי מוצר אחד יכולה לפעול שרשרת שלמה: ספק ענן, ספק מודל, שירות OCR, מסד וקטורי, מערכת ניטור, מערכת תמיכה ושירותים נוספים. גם זה אינו סימן למערכת לא טובה. כך בנויים שירותי תוכנה מודרניים. אבל כאשר ספק חיצוני נעזר בגורם נוסף לצורך השירות, תקנה 15 מחייבת להתייחס גם למערכת היחסים עם אותו גורם נוסף ולפיקוח לאורך ההתקשרות. לכן אתם צריכים לדעת לפחות מי הגורמים המהותיים בשרשרת, מה הם מקבלים, היכן מתבצע העיבוד ומה משתנה אם אחד מהם מוחלף.
המערכת שקניתם היום יכולה להשתנות מחר
ספק יכול להחליף מודל, להוסיף זיכרון, לשנות system prompt (הוראת מערכת שהספק מוסיף מאחורי הקלעים כדי לכוון את אופן פעולת המודל), להוסיף שירות חדש, לעבור לספק ענן אחר או לנתב שאילתות שונות בין כמה מודלים. אין בכך פסול כשלעצמו. לפעמים אלה בדיוק השינויים שמשפרים מוצר. אבל שינוי שמשפיע באופן מהותי על דרך עיבוד המידע, על זהות הגורמים שנחשפים אליו או על אופי השירות לא צריך להתרחש מבחינתכם בקופסה שחורה. גם כאן, המילה החשובה היא שקיפות.
ומה לגבי איכות התוצר?
כל האמור עד כאן אינו מחליף את הסיכון המוכר יותר: AI יכול לטעות. הוא יכול להחמיץ טענה, לפרש מסמך בצורה שגויה ולהפיק טקסט שנשמע מצוין אבל אינו נכון. המסקנה אינה להימנע ממנו. היא להשתמש בו ככלי עבודה ולא כמחליף לשיקול דעת מקצועי. האחריות לתוצר נשארת אצלכם.
לפני שאתם מעלים חומר של לקוח, בקשו תשובות בכתב
אתם לא צריכים להפוך לאנשי סייבר ולא לערוך לספק בדיקת חדירה. אבל אם אתם עומדים למסור לו חומר שאינו פומבי, ובוודאי מידע אישי, רפואי, חסוי, מסחרי או אסטרטגי, צריך להיות לכם מענה מסודר לפחות לשאלות המרכזיות: מי מעבד את המידע ומי ספקי המשנה; כיצד מופרדים לקוחות ותיקים; כיצד נשמרות הרשאות; האם כל סוג של קלט, לרבות פרומפטים, פלט ומשוב משמש לאימון או לשיפור; מה נשמר ולכמה זמן; מי יכול לגשת לתוכן; היכן הוא נשמר ומעובד; מה קורה בעת מחיקה; כיצד מטופל אירוע אבטחה; ומה קורה למידע בסיום ההתקשרות. ועכשיו צריך להוסיף לרשימה גם את הקניין הרוחני: מי שומר על הזכויות במסמכים שאתם מעלים, איזה רישיון אתם נותנים לספק לצורך הפעלת השירות, אילו זכויות מוקנות לכם בפלט, ואילו זכויות, אם בכלל, הספק שומר לעצמו. לא כל פרט צריך להפוך לסעיף חוזי. אבל בנושאים המהותיים הנוגעים לחיסיון, פרטיות, שימוש במידע, בידוד בין לקוחות וזכויות בתוכן, יש הבדל גדול בין תשובה של איש מכירות לבין התחייבות של החברה. אם אינכם יכולים לקבל את התמונה הזאת בכתב, אתם צריכים לעצור לפני שאתם מעלים חומר של לקוחות. לא משום שכל מערכת שאינה מספקת מסמך כזה בהכרח מפרה את החוק, אלא משום שללא המידע קשה לדעת על מה אתם מסתמכים, אילו סיכונים נטלתם והאם מילאתם את החובות שמוטלות עליכם ביחס למסירת מידע לגורם חיצוני.
לא להתרחק מ-AI. להשתמש בו מתוך ידיעה
AI הוא כלי עבודה מצוין, ובשימוש נכון הוא יכול לשפר באופן משמעותי את העבודה המשפטית. גם ספקי צד שלישי יכולים לבנות מערכות מצוינות, מאובטחות ומבודדות היטב. המסקנה אינה להתרחק מהם. היא להפסיק להתייחס אליהם כאל ממשק יפה שמחבר אתכם ל-GPT. כאשר אתם מעלים חומר של לקוחות, אתם בונים שרשרת אמון. אתם צריכים לדעת מי נמצא בה, מה כל חוליה עושה עם המידע, ומה קורה גם לזכויות בתוכן שנכנס למערכת ולתוכן שיוצא ממנה. לכן אל תשאלו רק איזה AI יש במערכת. שאלו מי נמצא ביניכם לבין ה-AI, מה קורה למידע שלכם בדרך, האם מישהו רשאי ללמוד ממנו, למי שייך מה שנוצר ממנו, ומה מונע ממנו להגיע למקום שבו הוא לא אמור להיות. אם יש תשובות טובות, כתובות ומחייבות, השתמשו בטכנולוגיה. אם אין, אל תתנו לנוחות של המערכת להחליף את הבדיקה שהייתם עושים לפני שמסרתם את אותו חומר לכל גורם חיצוני אחר.