This is as much a process question as it is a technical one.
Suppose your Civil3D models are in “real-world” cartesian coordinate space.
Let us also assume that your solution is for all AEC applications with the same understanding of that coordinate space.
The capabilities of different software with respect to real-world coordinates varies.
Microstation - excellent support
Civil3D - excellent support
Rhino - Variable perfomance/behaviours as the location is very far from 0,0 but manageable
Revit - Not great
Blender - 
There isn’t a universal mechanism to handle these capabilities with Speckle. A quick search will find plenty of examples and questions around this topic. As such, I don’t have a definitive answer for you. What you can do today, given your use-case of Civil3D and Revit, is to communicate a project standard for what Revit coordinate space should reference in order to handle “real-world” data. This is my preference from experience.
With that Project protocol in place, have Revit use the Survey Point and Project Basepoint to locate a known coordinate reference at Revit’s internal origin. Again, I have a preferred way of doing this, but every BIM lead has opinions.
Continue to use Civil3D as you were, and when receiving that data in Revit, use the Advanced Settings to specify, let’s say, the Survey point as the coordinate referencing method. I’m being vague here as your team may have set this up in many ways.
For your “all future AEC software”, there is a repeatable, reliable, but possibly undesirable methodology using automation. If you have a script in place which fires on every Version commit, that affine translates all the data to 0,0 from a given coordinate X,Y and writes that to a new Model called “Data (relocated)”
You could then reliably use that new Model data in Blender, Rhino, Unreal etc with no fear of it breaking the host application model.
All this assumed the same cartesian space version of geolocation and doesn’t account for Geomatic relocation, rotations, conversions to GPS etc.