איזו טלמטריה שולחים סוכני קידוד? מדריך לביקורת תעבורה

מה כוללת בפועל טלמטריה של סוכני קידוד

טלמטריה של סוכני קידוד מורכבת מארבעה זרמי נתונים נפרדים החולקים מונח אחד, כאשר לכל זרם יש בקרות משלו. הסקת מודל (model inference) מעבירה את ה-prompts ואת הקוד שלכם לספק המודל, ואין הגדרה שמבטלת זאת. ניתוח מוצר (product analytics) ודוחות קריסה נשלחים לספק, ולעיתים קרובות גם לחברת לוגים שהספק משלם לה. שמירת נתונים לצורך אימון היא סוגיה חוזית ולא סוגיה רשתית. הזרם הרביעי הוא זה שאנשים מפספסים: כל אינטגרציה שאתם מוסיפים עלולה לפתוח חיבור למארח שלא בחרתם בו מעולם.

רשימת ברירות המחדל הנוכחיות של הספקים היא החלק בנושא זה שמתיישן הכי מהר. גרסה חדשה יכולה לשנות ברירת מחדל, ותכונה חדשה יכולה להוסיף יעד שאף מתג קיים לא מכסה. לכן, המיומנות העמידה היא ביצוע ביקורת שניתן לחזור עליה מול כל סוכן: קראו את התיעוד של הספק, בדקו איזו תצורה הוחלה בפועל על המכונה הזו, נטרו את התהליך מהמכונה עצמה, ולאחר מכן בחרו את הבקרות שאתם מוכנים לשלם עבורן. כל פקודה להלן היא פקודה שאתם מריצים על המכונה שלכם, מול התעבורה שלכם.

ארבע הקטגוריות, ומדוע הן דורשות בקרות שונות

תעבורת הסקת מודל (Model inference) היא בלתי נמנעת. הסוכן שולח את ה-prompt שלך, את הקבצים שקרא, את הפלט של הפקודות שהריץ ואת הטקסט שהוא עצמו יצר אל נקודת קצה של מודל. זהו אופן הפעולה התקין של המוצר. ההחלטה היחידה היא מי מקבל את המידע: API שמנוהל על ידי גורם אחר, או מודל שאתה מריץ בעצמך. חשבון ענן ארגוני (כמו Bedrock, Vertex, או Foundry) משנה את היעד, אך לא מבטל את זרימת המידע. שום דבר בהמשך הפוסט הזה לא יפחית את תעבורת ההסקה, לכן הפרד אותה במחשבתך משלוש הקטגוריות האחרות.

ניתוח מוצר ודיווח על קריסות הם זרם שונה ליעדים שונים. מוני שימוש, נתוני latency, בדיקות feature-flag ו-stack traces נשלחים בדרך כלל לשמות מתחם שאין להם קשר ל-API של המודל, ולעיתים קרובות למערכת צד-שלישי לניטור שגיאות. ספקים מתעדים זאת בדרך כלל כ-"metrics" ו-"error reports" ומספקים לרוב משתנה סביבה אחד לכל קטגוריה. נפח התעבורה זניח, לכן מדידת בתים לא תסייע באיתורם. עליך לחפש שמות מתחם, לא רוחב פס.

שמירת נתונים ואימון הם עניין של מדיניות, לא של חבילות מידע. השאלה אם הספק שומר את ה-prompts שלך, לכמה זמן, והאם הוא מאמן עליהם מודל עתידי, מוגדרת בתנאי השימוש של התוכנית שלך. תוכניות לצרכן פרטי ותוכניות מסחריות נבדלות בדרך כלל זו מזו, והסדר של "אפס שמירה" (zero-retention) הוא לרוב הסכם נפרד. לא ניתן לאמת זאת באמצעות tcpdump, כיוון שהחבילה נראית זהה בכל מקרה. קרא את התנאים, ואם הנושא חשוב למעסיק שלך, דאג לקבל זאת בכתב.

אינטגרציות מוסיפות "דילוג" (hop) בשקט. שרת MCP (model context protocol), חנות תוספים, בדיקת עדכונים אוטומטית, כלי חיפוש ברשת, או בדיקת אבטחה המתרגמת URL לפני שליפתו: כל אחד מאלו הוא בקשה למארח שאינו נקודת הקצה של המודל. כאן טמונות ההפתעות, שכן תשתית עשויה לנתב עבודה שחשבת שהיא מקומית דרך שירות משלה, וגרסה חדשה (release) יכולה להתחיל לעשות זאת מבלי לשנות שורת קוד אחת בתצורה שלך. התייחס לכל כלי שאתה מוסיף כיעד חדש, עד שתנטר אותו בפועל על הרשת.

שלב 1: מה מתעד הספק?

פתחו את תיעוד ההגדרות ואת דף השימוש בנתונים של ה-agent שלכם, וקראו אותם תוך שימוש ברשימת מונחים: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace. כל אחד מהמונחים הללו הוא בדרך כלל מתג נפרד. רשמו את שמות המשתנים המדויקים, כיוון ששלב 2 משתמש ב-grep כדי לחפש אותם.

מונח אחד עלול להטעות אתכם. ב-agents רבים, המונח "telemetry" בתיעוד מתייחס לייצוא OpenTelemetry שאתם מגדירים כדי לשלוח מדדים ל-collector שאתם מריצים, וזהו מצב הפוך משליחת נתונים לספק. Claude Code הוא אחד מאלה: הגדרת CLAUDE_CODE_ENABLE_TELEMETRY=1 מתחילה ייצוא ל-endpoint שתציינו ב-OTEL_EXPORTER_OTLP_ENDPOINT, וזה אינו קשור ל-analytics של הספק עצמו, להם יש מנגנון opt-out שונה. ודאו מהו כיוון זרימת הנתונים לפני שתגדירו דבר מה.

צפו למתג ראשי, וצפו לכך שיהיו בו חורים. נכון לאוגוסט 2026, ה-CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC של Claude Code מכבה יחד מדדים, דוחות שגיאה, את פקודת ה-feedback וסקרים של סשנים, אך אותו תיעוד מציין שהוא אינו מכסה את בדיקת הבטיחות של הדומיין WebFetch, ששולחת את ה-hostname שאתם עומדים למשוך ל-API של הספק וכוללת הגדרה נפרדת משלה. זו אינה תלונה על מוצר ספציפי. זהו אופי הבעיה בכל מקום: מתג ראשי מכסה את הקטגוריות שהיו קיימות בעת כתיבתו.

צפו לכך שה-opt-out יעלה לכם במשהו. אותו תיעוד מציין שנטרול telemetry מנטרל גם את הערכת ה-feature-flag שחלק מהתכונות תלויות בה, כך שמתג שהופעל למען פרטיות עלול לכבות תכונה שאתם משתמשים בה, ללא הודעת שגיאה שמקשרת בין השניים. קראו את המשפט שליד הדגל, לא רק את שם הדגל.

שלב 2: איזו תצורה הוחלה בפועל?

הגדרה שכתבת אינה בהכרח הגדרה שהוחלה. סוכנים ממזגים תצורה מכמה קבצים, ואחד מהם נמצא בתוך המאגר (repository) שזה עתה שיבטת מאדם אחר. התחל בסביבת ה-shell שלך.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

לאחר מכן, הדפס את כל קובצי ההגדרות שהכלי קורא, לפי הסדר המצוין בתיעוד. עבור Claude Code, נכון לאוגוסט 2026, מדובר בקובץ המשתמש, שני קובצי הפרויקט, וספריית מדיניות מנוהלת ב-Linux.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

קובץ פרויקט שהגיע עם git clone הוא תצורה שנכתבה על ידי גורם זר, והוא יכול להפעיל מחדש הגדרות שקובץ המשתמש שלך ביטל. אם לסוכן יש פקודת סטטוס המפרטת אילו מקורות נטענו, זו הדרך המהירה ביותר להגיע לאמת: Claude Code מדפיס את מקורות ההגדרות שנטענו ב-/status.

הבדיקה המהימנה ביותר קוראת את התהליך הרץ במקום להסתמך על קבצים. תחילה, הקצה לסוכן חשבון משתמש Linux משלו, מה שהופך כל פקודה בפוסט זה לקצרה יותר, ולאחר מכן קרא את הסביבה שבה התהליך הופעל.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ מציג את המשתנים שהיו לתהליך בזמן ה-exec, כך שהוא מאתר מקרים שבהם ה-.bashrc שביצעת מעולם לא הגיע לשירות שהופעל על ידי systemd. אם משתנה שהגדרת חסר כאן, הוא מעולם לא נכנס לתוקף, ללא קשר למה שכתוב ב-dotfiles שלך.

שלב 3: לאילו מארחים הוא מתחבר?

התחילו בבדיקת sockets פתוחים, מסוננים לפי החשבון שבו רץ הסוכן.

sudo ss -tnpe state established

הפקודה -e מוסיפה שדה uid: לכל שורה, כך שתוכלו להפריד בין החיבורים של הסוכן לבין אלו של הדפדפן שלכם מבלי לקרוא את שמות התהליכים. רשמו את הכתובות המרוחקות, ולאחר מכן השיגו את השמות שמאחוריהן. המקור המהימן ביותר לשמות הוא ה-handshake של TLS (אבטחת שכבת תעבורה), כיוון שכל חיבור חדש מתחיל ב-ClientHello הנושא שדה SNI (חיווי שם שרת), שהוא שם המארח שהלקוח ביקש.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

תקבלו שורה אחת לכל חיבור חדש, וזהו בדיוק המלאי שאתם צריכים: ה-API של המודל, שרת העדכונים, מארח ה-analytics, עוקב השגיאות, וכל מה שתוסף כלשהו הוסיף. עמודת שם ריקה משמעותה שהלקוח השתמש ב-ECH (‏encrypted client hello), ולכן שם המארח אינו גלוי על גבי הרשת, ואתם נדרשים לחזור לכתובת ה-IP של היעד, לביצוע reverse lookup, או לשימוש ב-proxy בשלב 4.

תצוגת ה-DNS (מערכת שמות מתחם) היא כלי אימות צולב שימושי, כיוון שהיא מציגה שמות שהסוכן חיפש גם עבור חיבורים שלא הושלמו.

sudo tcpdump -ni any -l 'udp port 53'

כל שורת שאילתה מסתיימת בסוג הרשומה ובשם, בתבנית A? host.example.net. (39). בצעו את ה-capture על any ולא על הממשק החיצוני, כיוון שעם systemd-resolved היישום מדבר עם מאזין stub מקומי ב-127.0.0.53 ורק ה-stub מדבר עם העולם החיצון. אם אינכם רואים תעבורת DNS כלל בזמן שהסוכן עובד בבירור, סימן שסביבת ה-runtime מבצעת DNS over HTTPS בעצמה, ורק שלב 4 יספק לכם את השמות.

בצעו את ה-capture בזמן שהסוכן מבצע עבודה ממשית. התחילו session, גרמו לו לקרוא קובץ, להריץ פקודה, או להיכשל במשימה כלשהי. תעבורה שמופיעה פעם אחת בעת עלייה, או רק כאשר נזרקת חריגה, לעולם לא תופיע ב-capture של מצב סרק, ו-capture של מצב סרק הוא הדרך הנפוצה ביותר שבה ביקורת מגיעה למסקנה שגויה ונוחה.

שלב 4: מה נמצא בתוך הבקשות?

שמות מתחם (hostnames) מצביעים על היעד. כדי לראות את התוכן, הציבו proxy בשליטתכם לפני ה-agent והגדירו את ה-runtime לסמוך על ה-CA שלו. הכלי המקובל למשימה זו הוא mitmproxy. הפרויקט ממליץ על שימוש בקבצים בינאריים עצמאיים מ-mitmproxy.org, ומתעד את uv tool install mitmproxy כדרך להתקנה כחבילת Python.

mitmdump -w /tmp/agent-flows.mitm

בהרצה הראשונה נוצר CA בנתיב ~/.mitmproxy/, כאשר mitmproxy-ca-cert.pem הוא התעודה עצמה. ב-shell שממנו תפעילו את ה-agent, הגדירו את הלקוח להשתמש ב-proxy ובאותה תעודה.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

סוכני CLI רבים מבוססים על Node, ו-Node קורא את NODE_EXTRA_CA_CERTS בעת עליית התהליך. לכן, בצעו export למשתנה לפני הפעלת ה-agent, ולא בטרמינל אחר לאחר מכן. לקוחות Python קוראים את REQUESTS_CA_BUNDLE או SSL_CERT_FILE, וקובץ בינארי ב-Go המשתמש בספריות סטנדרטיות קורא את SSL_CERT_FILE ב-Linux. ודאו שהנתיב תקין באמצעות curl לפני שתסיקו שהבעיה ב-agent.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

proxy תקין מדפיס 200 והבקשה תופיע בפלט של mitmdump. שימוש ב-CA שאינו מהימן יניב curl: (60) SSL certificate problem: self-signed certificate in certificate chain, ובסוכן Node תתקבל שגיאה עם הקוד SELF_SIGNED_CERT_IN_CHAIN. לאחר מכן ניתן לקרוא את ה-flows שנשמרו באמצעות ממשק הקונסולה, שם ניתן לפתוח בקשה ולעיין ב-headers וב-body שלה.

mitmproxy -r /tmp/agent-flows.mitm

ישנן ארבע תוצאות אפשריות. אם אתם רואים את הבקשות, קראו אותן וקבלו החלטה. אם ה-agent מסרב לעלות בגלל שגיאת תעודה, מדובר בבעיית אמון ב-runtime ולא בממצא על הספק. אם אתם רואים רק את ה-API של המודל, ייתכן שהקטגוריות האחרות כבויות או שהן מופעלות באירוע שלא יזמתם. אם אינכם רואים דבר בעוד ה-agent עובד כראוי, סימן שהלקוח מתעלם ממשתני הסביבה של ה-proxy או מבצע certificate pinning, ובמקרה כזה שום הגדרה ביישום אינה אמינה. התוצאה האחרונה היא המשמעותית ביותר, והיא מחזירה אתכם לשלב 3, שכן packet capture אינו יכול להתעלם מחיבור קיים.

בקרות, מהחלשה לחזקה ביותר

הגדרות Opt-out. זוהי השיטה הזולה והחלשה ביותר, כיוון שהיא מסתמכת על כך שהספק יכבד אותן ועל כך שהן מכסות קטגוריה שכבר הייתה קיימת. הגדירו אותן כך שישרדו אתחול ופתיחת טרמינל חדש, בקובץ הגדרות המשתמש או ב־profile של ה־shell שלכם. הוסיפו את DO_NOT_TRACK=1 בזמן שאתם שם: זו מוסכמה שכלים רבים בשורת הפקודה מכבדים, כולל סוכנים מסוימים, והיא אינה דורשת מאמץ. לאחר מכן, הריצו שוב את שלב 3 לאחר העדכון הבא, שכן זהו הרגע שבו הכיסוי משתנה.

הגבלת תעבורה יוצאת (Egress). כאן אתם מפסיקים לבקש ומתחילים לאכוף. הריצו את הסוכן תחת משתמש ייעודי משלו, אפשרו לאותו משתמש גישה ל־loopback ול־DNS, וחסמו את כל השאר. פעולה זו מוסיפה טבלה משלה, כך שהיא אינה משנה חוקי firewall קיימים.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

יישמו זאת באמצעות sudo nft -f /etc/nftables.d/agent.nft, עקבו אחר המונה עם sudo nft list table inet agentegress, וקראו את החסימות עם sudo journalctl -k -g agent-egress-drop. מונה חסימות עולה עם שם מארח שלא ציפיתם לו הוא כל המטרה בתרגיל זה. ישנן שתי מגבלות כנות. meta skuid מתאים למשתמש שבבעלותו ה־socket, לכן הוא תקף רק כל עוד אותו חשבון אינו יכול להפוך למשתמש אחר: שימוש ב־sudo ללא סיסמה עבור הסוכן הופך את החוק הזה להמלצה בלבד. השארת פורט UDP 53 פתוח לכל שרת משאירה ערוץ שיכול להוציא נתונים בתוך שמות שאילתות, לכן סגרו גם אותו אם מודל האיומים שלכם דורש זאת, על ידי הפניית ה־resolver של הסוכן למארח שאתם מנהלים. רשימות היתרים (allowlists) של שמות מארחים שייכות ל־proxy ולא ל־nftables, כיוון שנקודות קצה של API יושבות מאחורי רשתות להפצת תוכן (CDN) שכתובות ה־IP שלהן משתנות תחת ידיכם. המחיר של בקרה זו הוא תקלות ותחזוקה: התקנות חבילות, git דרך SSH ובדיקת העדכונים של הסוכן עצמו – כולם ייכשלו עד שתאפשרו אותם, ורשימה זו היא כעת באחריותכם. אם אתם מגדירים זאת על שרת ולא על מחשב נייד, אותו מבנה של חשבון ו־firewall הוא הבסיס ל-הרצה בטוחה של Claude Code על גבי VPS.

מכונה זמנית (Disposable). תנו לסוכן מכונה וירטואלית (VM) שאינה מחזיקה בפרטי הזדהות שחשובים לכם ונהרסת בסיום המשימה. זה לא מפחית את מה שהסוכן שולח, אלא מפחית את מה שלסוכן יש גישה לשלוח, שזה בדרך כלל הסיכון שבאמת מעניין אתכם. שלבו זאת עם חוקי ה־egress לעיל, כיוון ש־VM חדשה עם גישה חופשית לאינטרנט עדיין מגיעה לכל מארח בלכידה שלכם. השיטה, והמצב שעליכם לשחזר בכל פעם, מכוסים ב-הרצת סוכני קידוד בתוך VM זמנית, ושאלת הגודל ב-הרצת סוכן קידוד על גבי VPS.

אירוח עצמי של המודל. הבקרה היחידה שמסירה את זרם ההסקה (inference), כיוון שה־prompt לעולם לא עוזב את החומרה שלכם. המחיר הוא אמיתי: אינכם יכולים לארח בעצמכם מודל סגור, לכן המשמעות היא בחירה במשקולות פתוחות וקבלת פער ביכולות במשימות קשות, בתוספת החומרה הנדרשת להרצתן. הפשרה מפורטת ב-האם ניתן לארח את Claude באופן עצמי, והבדלי היכולות בין הסוכנים העיקריים ב-כיצד Claude Code, Cursor, Codex ו-Copilot נבדלים זה מזה.

אף אחת מארבע בקרות אלו אינה משנה את מה שהסוכן מורשה לקרוא בדיסק, ותעבורת ההסקה נושאת את כל מה שהוא קורא. אם קובץ .env נמצא בתיקיית העבודה, הוא עובר למודל ברגע שהסוכן מבצע grep לשם משתנה. שמירה על חומר זה מחוץ להישג יד היא משימה נפרדת, המכוסה ב-שמירה על סודות מחוץ להקשר של סוכן AI.

מה לבדוק לאחר כל עדכון

1. בצעו השוואת diff בין דפי ההגדרות ושימוש הנתונים של הספק לבין מה שתיעדתם בפעם הקודמת, וחפשו מתגים חדשים ושירותים בעלי שמות חדשים.
2. קראו שוב את סביבת התהליך מתוך /proc/<pid>/environ כדי לוודא שהחרגות הוויתור (opt-outs) שלכם עדיין מוחלות על התהליך הרץ.
3. הדפיסו שוב את קובצי הגדרות הפרויקט, כיוון שפעולת git pull עלולה לייבא קובץ תצורה שקולגה שינה.
4. הריצו לכידת SNI עבור סשן עבודה מלא אחד ובצעו השוואה בין רשימת שמות המארחים (hostnames) לבין הרשימה הקודמת שלכם.
5. בדקו את מונה ה-drop של ה-firewall, שכן יעד חדש מופיע שם בדרך כלל לפני שתבחינו בו בכל מקום אחר.

תהליך זה אורך כעשר דקות והוא החלק היחיד בתהליך שאינו מתיישן. הגדרת ברירת מחדל שאימתתם באוגוסט 2026 היא עובדה נכונה לאוגוסט 2026. הלכידה היא עובדה נכונה להיום.

FAQ

האם ניתן למנוע מהסוכן (coding agent) שלי לשלוח את הקוד למודל?

לא, וכל הגדרה שטוענת שהיא עושה זאת מתייחסת למעשה למשהו אחר. שליחת ה-prompt, הקבצים שהסוכן קרא ופלט הפקודות שהריץ אל ה-endpoint של המודל היא הדרך שבה מתבצע ה-inference, לכן המשתנה היחיד הוא מי מקבל את המידע. ניתן לשנות את היעד על ידי הפניית הסוכן לחשבון ענן ארגוני או למודל שאתם מארחים בעצמכם, וניתן לצמצם את המידע שנשלח על ידי הגבלת הגישה של הסוכן לקבצים. כיבוי של analytics ושל דיווחי שגיאות אינו משפיע על תהליך זה כלל.

כיצד אוכל לראות לאילו מארחים (hosts) הסוכן מתחבר?

הריצו את הסוכן כמשתמש Linux נפרד, ולאחר מכן תפסו את ה-TLS ClientHello של כל חיבור חדש בזמן השימוש: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. שורה אחת תופיע עבור כל חיבור, עם כתובת היעד ושם המארח המבוקש. הצליבו שמות עם sudo tcpdump -ni any 'udp port 53', ובצעו את ה-capture ב-any, כיוון ש-resolver stub מקומי ב-127.0.0.53 מטפל בשאילתה תחילה. בצעו את ה-capture בזמן שהסוכן מבצע עבודה ממשית, שכן פינגים בעת עלייה ודיווחי קריסה לא יופיעו ב-capture של מצב המתנה.

ה-proxy שלי לא מציג תעבורה בזמן שהסוכן עובד. מה השתבש?

ייתכן שהלקוח מתעלם מ-HTTP_PROXY ומ-HTTPS_PROXY, או שהוא מבצע certificate pinning ומסרב לקבל את ה-CA שלכם. בדקו את הנתיב עם curl תחילה: אם curl מגיע לאינטרנט דרך ה-proxy והסוכן לא מופיע ברשימת התעבורה, הסוכן אינו משתמש במשתני הסביבה של ה-proxy. סביבות הרצה מסוימות דורשות שה-CA יסופק בדרך ספציפית, ו-Node בפרט קורא את NODE_EXTRA_CA_CERTS רק בתחילת התהליך, לכן ייצוא המשתנה לאחר הפעלת הסוכן לא יועיל. כאשר ה-proxy אינו יכול לראות את התעבורה, עברו ל-packet capture, שאף הגדרת יישום אינה יכולה לעקוף.

האם כיבוי ה-telemetry מונע מהקוד שלי לשמש לאימון?

לא. Analytics ודיווחי קריסות הם תהליך נפרד מ-inference, לכן נטרולם מסיר מוני שימוש ו-stack traces, אך משאיר כל prompt שנשלח למודל בדיוק כפי שהיה. השאלה האם ה-prompts הללו נשמרים, והאם הם משמשים לאימון מודל עתידי, נקבעת לפי תנאי התוכנית שלכם; תוכניות צרכניות ותוכניות מסחריות בדרך כלל שונות זו מזו. זהו חוזה שיש לקרוא ולא חבילת מידע שיש לתפוס, לכן בדקו את דף השימוש בנתונים של התוכנית שלכם, ובמידת הצורך, הסדירו הסכם מסחרי או הסכם ללא-שמירת-נתונים (zero-retention) לפני הסשן הראשון.