הבוט שלכם היה נכנס לשיחה בשקט ומתחיל לתמלל. עכשיו, בכל שיחה שמחזיקה אורחים בחדר המתנה, הוא יושב שם מתחת לאייקון אזהרה, ואם אף אחד לא פותח את חלונית המשתתפים בדקות הראשונות הוא פשוט לא נכנס, ואתם מסיימים את הפגישה בלי תמלול.
שום דבר לא נשבר אצל הספק שלכם. Google שינתה את האופן שבו Meet ממיינת בקשות הצטרפות, החל מ-24 במרץ 2026, והשינוי נוגע לכל מי ש-Meet מחליטה שמארח צריך להסתכל עליו פעמיים. בוטים של פגישות הם האוכלוסייה המתבקשת שנופלת בהגדרה הזו.
הניסוח המדויק חשוב כאן, כי הגרסה המקוצרת שמסתובבת ברשת לא נכונה. Google לא אסרה על כלי סיכום פגישות. היא פיצלה את תור הממתינים לשניים ושינתה איזה כפתור מסומן מראש.
המקור הראשוני, כפי שצולם ב-17 באוגוסט 2026: ההכרזה של Google, צילום המסך שלה, והניסוח שלה.
מה Google באמת שינתה
ההכרזה היא פוסט קצר אחד בבלוג Google Workspace Updates, Safeguarded guest admit flow in Google Meet, וכדאי לקרוא אותו במילים של Google ולא בסיכום של מישהו אחר. הפסקה הראשונה ממסגרת את זה כפיצ׳ר שמקל על המארח:
״The new safeguarded guest admit flow assists hosts in meetings when they respond to users who ask to join meetings (also known as 'knocking'). This makes it easier for hosts to handle large volumes of requests and helps reduce the attention and time needed.״
הפסקה השנייה היא זו שעצרה את הבוט שלכם:
״Meeting hosts will now get those requests presented in two separate queues. A new second queue now shows requests from connections where the host is more likely to need a closer look before deciding to approve them into the meeting. The default action for entries in this queue is to deny entry.״
והשלישית מציבה את התקרה:
״Hosts/co-hosts still remain in control and are always free to take another action than the default suggested.״
כלומר: שני תורים במקום אחד, פעולה מוצעת של דחייה בתור השני, ומארח שעדיין יכול לומר כן. זה כל המנגנון.
שתי שורות נוספות מאותו פוסט נוטות ליפול בין הכיסאות, ושתיהן משנות איך כדאי להיערך. תחת Getting started כותבת Google ״Admins: There is no admin control for this feature.״ צוות ה-IT שלכם לא יכול לכבות את התור השני עבור הדומיין. ותחת Availability: ״Available to all Google Workspace customers, Workspace Individual subscribers, and users with personal Google accounts.״ זו לא התנהגות של שכבת Enterprise שאפשר לצאת ממנה בכסף.
התאריכים מגיעים עם קצב השקה, והקצב הזה מסביר לא מעט שרשורי Slack מבולבלים מהאביב. דומיינים ב-Rapid Release התחילו ב-24 במרץ 2026, עם ״gradual rollout (up to 15 days for feature visibility)״. דומיינים ב-Scheduled Release התחילו ב-7 באפריל 2026 באותו קצב הדרגתי. אם הבוט שלכם המשיך לעבוד עוד שבועיים בזמן שאצל עמית בחברה אחרת הוא נעלם בסוף מרץ, הפער הזה הוא מסלול ההשקה ולא הגדרה שאחד מכם שינה.
הסתייגות אחת לגבי מקורות, כי מישהו עוד יצטט את המאמר הזה כראיה: גוף הטקסט של הפוסט של Google לא משתמש במילים bot, notetaker או third-party אפילו פעם אחת. Google מתארת ״connections where the host is more likely to need a closer look״ ומשאירה את האוכלוסייה לא מוגדרת. הקישור לכלי סיכום פגישות מגיע משני מקומות. הראשון הוא צילום המסך של Google עצמה שמוטמע באותו פוסט, שבו הרשומה המסומנת היא אווטאר בשם ״Anon.Bot״. השני הוא ספק שסיפר ללקוחות שלו מה קרה: מרכז העזרה של Metaview קורא לזה ״a Google-wide change affecting all notetakers, not a Metaview issue״.
מה המארח רואה כשהבוט שלכם מבקש להיכנס
צילום המסך בהכרזה של Google הוא התמונה הברורה ביותר שיש כרגע של החלונית החדשה, וזה ממשק המוצר האמיתי ולא המחשה של הרעיון. בראש השיחה מופיעה גלולה שכתוב בה ״5 guests waiting״. פתיחה שלה מציגה חלונית בכותרת ״Waiting to join״, מסומנת ״Visible to hosts״, מפוצלת לשני מקטעים. העליון אומר ״1 with potential risk״ עם אייקון אזהרה, ומתחתיו אווטאר בודד בשם ״Anon.Bot״. התחתון אומר ״4 confirmed users״ ומונה אותם בשמות: Adam J, Sarah M, Mark, Sophia L. הכיתוב של Google מתחת לתמונה קורא לזה ״New notifications and people panel updates for the improved admit flow״.
הבוט שלכם יושב שם ממוין, מתויג ומסומן מראש לסירוב, בתוך חלונית שמישהו צריך לפתוח. ״Potential risk״ היא המחרוזת המילולית שמארח קורא ליד הכלי שאתם משלמים עליו, וכדאי לדעת את זה לפני שלקוח רואה את זה בפגישה שלכם.
בקהילת Google Meet יש שרשור בשם "How to prevent custom Google Meet bot from being flagged as 'Potential Risk'?", שלכל הפחות מאשר שזו התווית שמשתמשי קצה פוגשים במוצר. זה פורום משתמשים, אז התייחסו לשרשור כעדות לכך שאנשים נתקלים בזה ולא יותר.
מה עדיין עובד
רוב התהליך שרד. רוב מה ששרד דורש עכשיו בן אדם שיהיה ער לזה, ומסלול אחד עוקף את התור החדש לגמרי.
פגישות שאף אחד לא צריך לדפוק בדלת שלהן לא מגיעות לתור השני בכלל. Google מגדירה את היכולת סביב ״knocking״. המשפט הראשון בפוסט שלה אומר שהזרימה ״assists hosts in meetings when they respond to users who ask to join meetings (also known as 'knocking')״. אם הפגישה מכניסה אורחים ישירות, אין דפיקה בדלת, אין תור ואין ברירת מחדל שדוחה. Metaview מפרטת את ההגדרה למשתמשים שלה: כאשר Meeting access type מוגדר כ-Open, ״anyone can join directly. There is no waiting room, and the Metaview Notetaker can join automatically״. ההמלצה שלה ישירה: ״For reliable capture, we recommend setting Meeting access type to Open.״ רק תהיו מודעים למה שאתם מוותרים עליו. קישור פתוח מאפשר לכל מי שמחזיק בו להיכנס, וזו בדיוק הבעיה ש-Google בנתה בשבילה את התור השני. הגדירו את זה לכל פגישה בנפרד ומתוך כוונה, לא כברירת מחדל גורפת על כל היומן.
גישת Trusted עם חדר המתנה פעיל, בתוספת האישור האוטומטי של הספק שלכם. לצוותים שמדיניות החברה שלהם פוסלת Open, ההנחיה של Metaview עצמה היא: ״If your company policy requires Trusted access, make sure Waiting room is enabled. You can also turn on Bring in automatically so the Notetaker is admitted when a host joins.״ זו יכולת של Metaview וזו הטענה של Metaview לגביה. Google לא מתעדת איך אישור אוטומטי של ספק כלשהו מתנהג מול התור המסומן החדש, אז התייחסו לזה כאל משהו שכדאי להגדיר ואז לבדוק בשיחה אמיתית, לא כאל הבטחה.
מארח או מארח משנה עדיין יכולים להכניס את הבוט. זו התשובה לפניית התמיכה, וזו אותה לחיצה שתמיד הייתה, רק שהיא נעשית עכשיו מחלונית שמציעה את ההפך. Metaview, ספקית של כלי סיכום פגישות, מתעדת את התנועה המדויקת עבור הבוט שלה: ״click on 'Admit', or on the three dots (⋮) next to the Metaview Notetaker and select 'Admit entry'״. המשפט של Google, שמארחים ומארחי משנה ״are always free to take another action than the default suggested״, הוא מה שמאפשר את זה.
תדריך מראש למארח. מכיוון שהחלונית מראה שם ואייקון אזהרה ולא הרבה יותר, מי שמנהל את השיחה צריך לדעת מראש שבוט יבקש להיכנס ושעכשיו הוא דורש אישור מכוון. שורה בהזמנה ביומן תורמת לשיעור התמלולים שלכם יותר מכל הגדרה אצל הספק.
תזמון, עם הסתייגות שתלויה בספק. Metaview אומרת למשתמשים שלה שמארח צריך לאשר תוך 5 דקות ממועד הפתיחה המתוכנן, אחרת הבוט מוסר מחדר ההמתנה. החלון הזה הוא ההתנהגות של Metaview ולא משהו ש-Google מתעדת בפוסט הזה, אז בדקו את המספר של הספק שלכם במקום להניח חמש דקות בכל מקום. הלקח הכללי נשאר: האישור צריך לקרות מוקדם, בדיוק כשאנשים עוד מתיישבים והכי פחות סביר שיסתכלו על חלונית צדדית.
מה שלא שרד בשלמותו זו האמינות ללא השגחה בשיחות שמחזיקות אורחים בחדר המתנה, וזה רוב השיחות ברוב החברות. לפני מרץ, בוט על פגישה חוזרת היה משהו שמגדירים פעם אחת. עכשיו, בכל פעם שהפגישה שולחת אורחים לחדר המתנה, נוסף לשיחה שלב שתלוי בכך שמישהו ישים לב לחלונית בדקות הראשונות.
לאותה חלונית Video call options יש הגדרה שפועלת בכיוון ההפוך, והיא זו שבאמת חוסמת במקום להמתין לאישור. Metaview מציינת שכאשר הגישה ל-Meet מוגדרת כ-״Trusted״ או ״Restricted״ וחדר ההמתנה מכובה, ״external guests, including bots, are blocked instead of held for admission״. בניגוד לתור המסומן, להגדרה הזו כן יש מתג בקונסולת האדמין. עמוד העזרה לאדמינים של Google, Manage meeting access settings for your users, אומר לצוותי IT ש-״As the IT administrator for your organization, you can create default access settings for meetings within your organization״, מתוך Meet safety settings בקונסולת הניהול, עם אפשרות להחיל את זה לפי יחידה ארגונית, ומוסיף ש-״Users can change these settings for meetings they create״. כלומר יש שני מקומות שבהם זה נקבע. ברירת המחדל הארגונית היא של האדמין, והמארח דורס אותה בפגישה מסוימת: העמוד של Metaview אומר ״A Google Meet host or co-host can change these settings״, מתוך יומן Google, על ידי פתיחת אירוע קרוב ולחיצה על אייקון גלגל השיניים כדי להגיע ל-Video call options, שם Meeting access type יושב תחת Host controls. כשה-IT נעל את ההגדרה, הדריסה הזו כבר לא בידי המארח, ו-Metaview אומרת את זה פעמיים: פעם כהסתייגות, ״If your Google Meet settings are controlled by your IT administrator, you may need to contact them to make these changes״, ופעם כעצה, כשהיא מציעה למשתמשים ״ask your Google Workspace admin to set meeting access and host-management defaults so notetakers can be admitted automatically״. בדקו את שני הקצוות לפני שאתם מאשימים את התור השני: סוג גישה שחוסם יעצור את הבוט שלכם לא משנה כמה מהר מישהו ילחץ על אישור.
החלק שאף ספק לא הולך לתקן
לכל כלי סיכום פגישות שעובד בשיטת ההצטרפות לשיחה יש אותה תלות: הוא צריך שפלטפורמת הפגישות תמשיך להכניס משתתף שאינו אדם, והוא צריך שבן אדם יאשר אותו כשהפלטפורמה מפסיקה לעשות את זה אוטומטית. Google שינתה את ברירת המחדל ב-24 במרץ, בלי שליטת אדמין על היכולת עצמה, והספקים גילו את זה באותה דרך שאתם גיליתם.
זו החלטה סבירה מצד Google. פגישה שיושב בה חשבון לא מזוהה היא שאלת אבטחה אמיתית, ותור שברירת המחדל בו היא דחייה הוא תשובה שאפשר להגן עליה. זה גם סיכון מבני קבוע לכל מי שההערות שלו תלויות בכך שיאשרו לו כניסה.
החלופה היא פשוט לא לבקש להיכנס.
להקליט את החדר במקום להצטרף אליו
אנחנו בונים את Routines, אפליקציית Mac שמייצרת סיכומי פגישות בלי לשלוח שום דבר לפגישה. היא מקליטה שני זרמי אודיו מקומיים: את המיקרופון שלכם, דרך זרם קלט אודיו רגיל, ואת האודיו המערכתי שה-Mac כבר מנגן, דרך process tap של Core Audio, שדרכו נקלטים שאר האנשים בשיחה. אם הזרם המערכתי לא מצליח לעלות על מכונה מסוימת, ההקלטה ממשיכה עם המיקרופון בלבד במקום להיכשל, וכדאי לדעת את זה כי זה המצב שבו תקבלו את הצד שלכם בשיחה ולא את הצד שלהם. אותו tap הוא גם הסיבה שהקלטת פגישה לא מבקשת מכם הרשאת הקלטת מסך של macOS. אף חשבון לא דופק בדלת, שום דבר לא מופיע ברשימת המשתתפים, ואין רשומה בתור האישורים שברירת מחדל יכולה לדחות. לשינוי של Google אין כאן משטח לפעול עליו.
פגישה גמורה ב-Routines: סיכום, משימות ותמלול, נשמרים כקובץ markdown בתיקייה שאתם בוחרים.
היתרון הזה מגיע עם פער שאנחנו מעדיפים להגיד בעצמנו ולא שתגלו לבד, והוא כבר כתוב באותן מילים במרכז השקיפות שלנו. Routines לא כוללת סימון גילוי, לא הודעה אוטומטית בצ׳אט של הפגישה, ולא בקשה שמופנית לשאר המשתתפים לאשר את התיעוד. לומר לאנשים בחדר שאתם מתעדים זו האחריות שלכם, ואנחנו ממליצים לומר את זה בקול בתחילת השיחה. בוט ברשימת המשתתפים לפחות מכריז על עצמו. מקליט מקומי לא, ולכן ההכרזה נופלת עליכם.
החוק מסכים עם המסגור הזה, וזה החצי הפחות נוח. כללי ההקלטה נשענים על הסכמה ולא על השאלה אם המקליט מופיע ברשימת המשתתפים, כך שהקלטה מקומית שקטה עומדת באותו מבחן כמו בוט גלוי. בארצות הברית הרצפה הפדרלית היא הסכמה של צד אחד, וכמה מדינות, ביניהן קליפורניה, פלורידה, אילינוי ופנסילבניה, דורשות הסכמה של כל הצדדים. בדקנו את נוסח החוק ב-2026-08-10, וזה מידע כללי ולא ייעוץ משפטי.
לאן הולך האודיו זה הדבר השני שצריך לומר בבירור, כי ״מקליט על ה-Mac״ נקרא כהבטחה שהוא לא נותן. הקליטה מקומית. אודיו הפגישה זורם ל-Deepgram לתמלול והפרדת דוברים, על המפתח שאנחנו מנהלים אם אתם ב-Pro או בתקופת הניסיון, ועל מפתח Deepgram שלכם בתוכנית ה-Free. המסלול נקבע לפי קיומו של מפתח Deepgram ולא לפי מצב שאתם בוחרים. הסיכום והמשימות נוצרים על ידי המודל שאתם מחברים, כך שגם השלב הזה דורש חיבור. ההערות נוחתות כ-markdown בתיקייה שאתם בוחרים, התמלולים יושבים במסד הנתונים המקומי של האפליקציה, וגיבוי וסנכרון בענן כבויים כברירת מחדל. תדליקו אותם ועותקים יישמרו בחשבון Routines שלכם כדי שהמכשירים שלכם יחלקו אותם.
אחרי השיחה אפשר לשאול שאלות מול התמלול ולשלוף החלטות ומשימות המשך.
אם אתם שוקלים את זה מול הכלי המוביל בשוק, Routines מול Granola עובר על הפשרות לעומק, כולל אלה ש-Granola טובה בהן יותר. גם Granola קולטת אודיו על המחשב במקום לשלוח בוט לשיחה, ובמילים שלה עצמה, כפי שהן מצוטטות בביקורת שלנו על Granola, ״No bot joins your meeting״, ולכן לשינוי של Google אין על מה לפעול גם שם. ההבדל הוא מה קורה להערות אחר כך, ולא מי עובר את חדר ההמתנה.
האפליקציה היא הורדה חינם ל-macOS אם בא לכם לבחון אותה על השיחה הבאה שלכם.
שאלות נפוצות
האם Google אסרה על בוטים של סיכום פגישות ב-Google Meet?
לא, וכדאי לדייק כאן כי הגרסה המקוצרת שמסתובבת ברשת פשוט לא נכונה. הפוסט של Google בבלוג Workspace Updates שמכריז על safeguarded guest admit flow מתאר שינוי באופן שבו בקשות הצטרפות ממוינות: ״Meeting hosts will now get those requests presented in two separate queues. A new second queue now shows requests from connections where the host is more likely to need a closer look before deciding to approve them into the meeting. The default action for entries in this queue is to deny entry.״ אותו פוסט מוסיף ש-״Hosts/co-hosts still remain in control and are always free to take another action than the default suggested.״ ברירת מחדל היא לא איסור. מארח שפותח את החלונית ובוחר להכניס עדיין מכניס את הבוט.
למה כתוב ליד הבוט שלי ״potential risk״ בחדר ההמתנה של Google Meet?
כי הוא נחת בתור השני. צילום המסך של המוצר שמופיע בפוסט ההכרזה של Google מראה את חלונית ההמתנה עם מקטע שכותרתו ״1 with potential risk״ ומתחתיו אווטאר בשם ״Anon.Bot״, ומקטע נפרד שכתוב בו ״4 confirmed users״ עם שמות המשתתפים. לפחות ספק אחד של כלי סיכום פגישות תיעד את אותה התנהגות עבור הבוט שלו. מרכז העזרה של Metaview מסביר למשתמשים שלו שמסוף מרץ 2026 Google Meet מסמנת כל בוט פגישות ״with a 'potential risks' label in the waiting room״, וקורא לזה ״a Google-wide change affecting all notetakers, not a Metaview issue״.
מתי זה התחיל, והאם זה נוגע לכל חשבון Google?
הפוסט של Google נותן שני תאריכים ושני מסלולים. דומיינים ב-Rapid Release קיבלו השקה הדרגתית, עד 15 יום עד שהיכולת מופיעה, החל מ-24 במרץ 2026. דומיינים ב-Scheduled Release התחילו ב-7 באפריל 2026 באותו קצב הדרגתי. הזמינות רחבה: ״Available to all Google Workspace customers, Workspace Individual subscribers, and users with personal Google accounts.״ אם הבוט שלכם המשיך להיכנס עוד שבועיים בזמן שאצל עמית הוא הפסיק בסוף מרץ, הפער הזה הוא מסלול ההשקה ולא ההגדרות שלכם.
איך מכניסים עכשיו בוט סיכום פגישות ל-Google Meet?
המארח או מארח משנה מכניסים אותו מחלונית המשתתפים, בדיוק כמו כל אורח, רק שהם צריכים לבחור פעולה אחרת מזו שסומנה מראש. ההוראות של Metaview לבוט שלה מייצגות את התהליך: ״click on 'Admit', or on the three dots (⋮) next to the Metaview Notetaker and select 'Admit entry'״. Metaview גם מזהירה את המשתמשים שלה שהמארח צריך לפעול תוך 5 דקות ממועד הפתיחה המתוכנן, אחרת הבוט מוסר מחדר ההמתנה, וזה תזמון של אותו ספק ולא משהו ש-Google מתעדת. הפתרון המעשי הוא לומר למארח מראש שבוט יבקש להיכנס ושצריך לאשר אותו ידנית. אפשר גם להוריד את הדפיקה בדלת לגמרי: Google מגדירה את הזרימה סביב פגישות שבהן אורחים מבקשים להצטרף, ולכן בפגישה שבה Meeting access type מוגדר כ-Open אין חדר המתנה שאפשר למיין אליו. בלשונה של Metaview, ״anyone can join directly. There is no waiting room, and the Metaview Notetaker can join automatically״, והיא ממליצה על זה בדיוק ״for reliable capture״. המחיר הוא שכל מי שמחזיק בקישור יכול להיכנס. אם המדיניות שלכם מחייבת גישת Trusted, החלופה של Metaview היא להשאיר את חדר ההמתנה פעיל ו-״turn on Bring in automatically so the Notetaker is admitted when a host joins״, שזו יכולת של אותו ספק ו-Google לא מתעדת אותה מול התור המסומן החדש, אז בדקו בשיחה אמיתית.
האם אדמין יכול לכבות את התור השני?
לא את זה. הפוסט של Google מפורש תחת Getting started: ״Admins: There is no admin control for this feature.״ קיימת הגדרה נפרדת ומחמירה יותר שפועלת בכיוון ההפוך, ולה כן יש אדמין מאחוריה. Metaview מציינת שכאשר הגישה ל-Meet מוגדרת כ-Trusted או Restricted וחדר ההמתנה מכובה, ״external guests, including bots, are blocked instead of held for admission״. את Meeting access type קובעים בשני מקומות. עמוד העזרה לאדמינים של Google אומר ש-״As the IT administrator for your organization, you can create default access settings for meetings within your organization״, מתוך Meet safety settings ולפי יחידה ארגונית, ומוסיף ש-״Users can change these settings for meetings they create״. את השינוי לפגישה בודדת עושה המארח מתוך יומן Google, בפתיחת האירוע ולחיצה על גלגל השיניים כדי להגיע ל-Video call options, כאשר Meeting access type נמצא תחת Host controls, ו-Metaview מאשרת ש-״A Google Meet host or co-host can change these settings״. אם ה-IT נעל את ההגדרה, המארח צריך לפנות אליהם, וזה בדיוק מה ש-Metaview אומרת למשתמשים שלה. היא חוסמת במקום להמתין לאישור, אז שאלו את המארח, ואחר כך את האדמין, לפני שאתם מניחים שדווקא התור השני הוא זה שעצר את הבוט. לאותה הגדרה יש אפשרות שפועלת בכיוון ההפוך: כאשר Meeting access type מוגדר כ-Open, לפי Metaview, ״anyone can join directly. There is no waiting room, and the Metaview Notetaker can join automatically״, כלומר אין תור שברירת המחדל תחול עליו. את סוג הגישה בוחר המארח לכל פגישה או האדמין קובע אותו כברירת מחדל ארגונית; מה שאין לו מתג אדמין זה התור המסומן עצמו.
אפשר לקבל סיכומי פגישות בלי שבוט מצטרף לשיחה?
כן. הקלטה על המכשיר עצמו היא הארכיטקטורה השנייה. Routines מקליטה שני זרמי אודיו מקומיים על ה-Mac שלכם, את המיקרופון שלכם ואת האודיו המערכתי שה-Mac כבר מנגן דרך process tap של Core Audio, כך שאף אחד לא דופק בדלת, שום דבר לא מופיע ברשימת המשתתפים, ואין רשומה בתור האישורים שאפשר לדחות. כדאי לומר בקול לאן האודיו ממשיך משם: אודיו הפגישה זורם ל-Deepgram לתמלול, על המפתח שאנחנו מנהלים אם אתם ב-Pro או בתקופת הניסיון, ועל מפתח Deepgram שלכם בתוכנית ה-Free. המסלול נקבע לפי קיומו של מפתח Deepgram. שלב הסיכום דורש חיבור למודל בנוסף. פער אחד שייך לאותה נשימה: Routines לא כוללת סימון גילוי, לא הודעה אוטומטית בצ׳אט של הפגישה ולא בקשת הסכמה, כך שלומר לאנשים בחדר שאתם מתעדים זו האחריות שלכם ולא של האפליקציה.
מקורות
- צוות Google Workspace, "Safeguarded guest admit flow in Google Meet", Google Workspace Updates, פורסם ב-24 במרץ 2026, נבדק ב-17 באוגוסט 2026
- Google, "Add or remove people from a Google Meet meeting or call", מרכז העזרה של Google Meet, מקושר כהפניה למשתמשי קצה מתוך ההכרזה שלמעלה
- Google, "Manage meeting access settings for your users", מרכז העזרה לאדמינים של Google Workspace, בעמוד רשום ״Last updated 2026-08-14״, נבדק ב-17 באוגוסט 2026
- Metaview, "Google Meet", מרכז העזרה של Metaview, נבדק ב-17 באוגוסט 2026
- קהילת Google Meet, "How to prevent custom Google Meet bot from being flagged as 'Potential Risk'?", שרשור משתמשים, נבדק ב-17 באוגוסט 2026
- Routines, "שקיפות: הסכמה וגילוי הקלטה", הביקורת שלנו על מה ש-Routines עושה ומה לא, נבדק לאחרונה ב-10 באוגוסט 2026