NanoCo גייסה 12 מיליון דולר והשאירה את כפתור השליחה לאדם

|כותב: מערכת QUASA|5 דק׳ קריאה
NanoCo גייסה 12 מיליון דולר והשאירה את כפתור השליחה לאדם

ב־28 באוקטובר 2026 חזר דיווח על NanoCo לסבב סיד של 12 מיליון דולר שהחברה כבר גייסה, בהובלת Valley Capital Partners ובהשתתפות Docker, Vercel ו־monday.com; הוא לא תיאר גיוס נוסף באוקטובר. לייזר כהן, ממייסדי החברה, ניסח שם את השאלה שהניעה את הפיתוח: “whether it could really be trusted with company data”.

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

מה מממן סבב הסיד של NanoCo

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

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

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

היכן נעצרות ההרשאות של NanoClaw

סוכני NanoClaw פועלים בסביבות נפרדות עם גישה המוגבלת למשימות שהוגדרו להם.

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

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

יש כאן גבול שחשוב להציג במדויק: סקירה עצמאית של NanoClaw מה־12 באוקטובר 2026 מצאה שבפרויקט הפתוח אישור אנושי לשימוש בסוד תלוי בהגדרה, וכי הגבלת יציאה ישירה לרשת אינה מופעלת כברירת מחדל בהתקנה שנבדקה. הסקירה עוסקת בפרויקט הפתוח, ולא בבדיקת פריסה של המוצר הארגוני. לכן אי אפשר להסיק מן ההבטחה המסחרית שכל התקנה עצמאית של NanoClaw עוצרת כל שליחה או חיבור ללא אישור.

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

מה קורה בין טיוטת מייל לשליחה

הודעת המשך ללקוח שהכין NanoClaw ממתינה לאישור אנושי לפני שליחה.

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

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

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

היכן נשמר מידע העבודה

NanoCo מציגה אפשרות להפעיל את המוצר בחשבון הענן של הלקוח ב־AWS, ב־GCP או ב־Azure. לפי החברה, סביבת הסוכנים והידע שהם צוברים נשארים בשליטת הארגון בפריסה כזאת. עבור צוות שעובד עם מסמכי לקוחות, זו הבחנה מעשית: היא קובעת מי מנהל את סביבת העבודה שבה נשמר ההקשר של הסוכן ומי מגדיר את הגישה אליו.

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

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

קראו גם:

שיתוף:

הירשמו לניוזלטר שלנו

קבלו את החדשות האחרונות על Web3, ‏AI וקריפטו ישירות לתיבת הדואר.

0